[openbeos] Re: A new BMessage implementation (Message4)
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 02 Nov 2005 05:31:09 +0100
> I honestly think that we need to add to the benchmarks. I would like
> to see something where you pick 10 or so different system messages
> (i.e. messages that the OS creates) and create numbers of those.
Yes, the benchmarks presented on my site are just the timings from the
(extended) UnitTests of BMessage. In my local testing apps that I built
the implementation with are kind of more complex and have a bigger
varity of tests. They pretty much all outperform R5 on reasonably large
messages (up to about 500 fields). Otherwise I would have abandoned
Message4 right away ;). I will sure try to improve the BMessage
UnitTests to that extend that they include some more "real life"
situations. The benchmarks as of now are more like indications of speed
to decide if we want to go in a direction of an implementation at all.
> Secondly - I am concerned about having a different Flatten/Unflatten
> format.
> Only because of people (like me) who would like to upgrade their R5
> system to Haiku by copying a couple of directories over. Losing all of
> my settings would irritate me. :-) Isn't it possible to check the
> version of the flattened data and instantiate it correctly?
Don't worry. That's what I meant by the "R5 message reader". Axel
implemented a message reader for Dano messages that unflattens them into
Haiku BMessages. The same can be easily (as there are already
implementations of that) done for R5 messages. So copying over from R5
to Haiku will not be a problem. Only the other way around will not work
(like going from Dano to R5 doesn't work).
> If there's any part of the system that does something to raw
> BMessages, (snooping on them as they pass by?) other than
> flattening/unflattening and using the class methods, a complex
> flattened format may be less desirable, performance-wise. No?
Well, most parts of the system will receive messages which involves a
Flatten/Unflatten. So reducing Flatten/Unflatten overhead was one of the
main goals of this implementation. For looking at the message with
BMessage methods should not be more complex due to the new format. It
still involves doing a hash on the name, looking through the hash table,
finding the offset into the message data and then reading from there.
The only difference is that "finding the offset" is done by actually
calculating the offset and not using pointers to it. This shouldn't be a
problem for day to day use at all.
Regards
Michael
Other related posts:
