[openbeos] Re: A new BMessage implementation (Message4)

  • From: mmlr@xxxxxxxx
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 4 Nov 2005 17:08:42 +0100 (CET)

> 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.




Other related posts: