> Have you compared your results with the Dano BMessage > implementation? I would assume that it outperforms R5 quite > often. No, I have not tested them against Dano as I don't use any Dano here. After searching for and reading about the Dano message format (especially this: http://www.qube.ru/news/item/dianne_hackborn_about_bmessage_in_beos_5_1/) I came to the conclusion that it was implemented with pretty much the same goals as Message4. This is not very surprising looking at the arkward format of R5 messages where it is simply impossible to get speeds like these because of all that variable sized headers / flags / data items. The outcome of Message4 is similar to the one in Dano, it just doesn't sort and binary search fields but uses a hash table. Message4 currently stores all its information into the flat message (reply info, hash table, specifier stuff) which is not really necessary. The hash table can be recreated (or, if we would go with sorted lists like Dano, could be left out completely) and the reply info will most probably be invalid by the time of unflattening anyway and can therefore go too. As far as I understand the Dano message format there are no field flags at all. And there is no distinction between fixed size or not. As I currently don't have access to a BeOS or Dano I cannot check that right now, so I base this on looking at dano_message.cpp. To sum it up: Dano messages are simple and fast and it would be easily possible to transform Message4 into something very similar to the Dano format producing compatible output. So what about just going this way and leave that R5 message format as a reader only? This would make us compatible with Dano / ZETA and we could start from there togheter. As much as I don't like to say it (as an R5 only user), but we should just dump the R5 format - it just isn't efficient in anything other than it's space savings. I'm sorry that I still haven't checked in that Message4, but I just want to get it working first. I thought that it would work right away, which was not (as most of the time) the case. It's now kind of working, but if we could agree on using the Dano format, I could squeeze that refactoring in beforehand.