[openbeos] Re: A new BMessage implementation (Message4)
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 02 Nov 2005 19:23:25 +0100
> Ah, so you only have to iterate over all fields when unflattening? (to
> create the fFields array)
No, not at all. The FieldsBuffer is an array of FieldHeaders. They
contain the same data as the field headers of R5 messages, but are fixed
size (since the name is and data is in the DataBuffer). The FieldsBuffer
is copied when flattening / unflattening and left in tact at all times.
Nothing has to be rebuilt at unflatten time - that's the point of
Message4 actually.
> I meant for the field data, right. How iterating works now is clear,
> it's just a question of how often you have to do it (if such an offset
> table can make any sense).
You have to iterate through the items every time you want to know the
size of a specific item or when you want to read that item. Currently no
list of direct offsets is kept. Message3 has keeps a list of offsets so
it's obviously faster when reading many items with a high index. But the
disadvantage is that a list of offsets has to be kept in sync when
adding/removing/resizing data and has to be built at unflatten time.
This is what I wanted to avoid actually, because I think most messages
will just not include enough variable sized items that this investment
of cycles and memory would be worth it. Judging by the benchmarks, R5
does not have an offset table either because it performs roughly the same.
> BTW don't forget the new (and private) _kern_writev_port_etc() call
> when sending the message - that saves you creating a single large
> buffer to write into a port.
Yeah, but with Message4 you really only have three buffers that you can
copy pretty much right away. I'll change that though.
> Sure, we could do the same, but I never liked Be's solution there. The
> new Flatten() prototype is okay, and we should use it as well - but I
> don't like to introduce just another on-disk storage format for
> BMessages. Two different formats is already causing more headaches
> than necessary.
Hmm. Yes, I don't like to introduce another storage format either and
had my worries about that too while implementing it. But in the end, why
is it that much of a problem? No application should actually care about
the raw format of a flattened message. They don't have to either. The
really only thing that is a problem is that you cannot just copy over
settings files from one system to another.
> Also, for on-disk storage, the R5 format is more efficient.
It is mostly optimized to use as few bytes as possible. While I think
that is is a good thing, I'd much rather preferr an implementation that
is just quicker in loading the message at hand than the 20 bytes saved.
I mean disk space is not really the issue is it?
I'll work on integrating and finishing Message4 this evening again. I
hope to bring it as far as having a drop in replacement. You should take
a look at the code when it's checked in, it should clear up most of the
questions. For me at least, it is very straight forward, but that's
maybe just due to me writing it...
Regards
Michael
Other related posts:
