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

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Michael Lotz <mmlr@xxxxxxxx> wrote:
[...]
>  > 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.

Have you compared your results with the Dano BMessage implementation?
I would assume that it outperforms R5 quite often.

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

Nice :)

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

Settings files, and possibly data files as well. For example 
WonderBrush stores its native file format as BMessages - there might be 
more examples of that.
Applications like WonderBrush will probably be available for Zeta, R5, 
and Haiku. IMO, if we introduce a messaging format Zeta does not 
support, we're asking for trouble - and our fellow users will have to 
pay for it.

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

Right, it's not really a good argument :-)

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

Okay, thanks :-)

Bye,
   Axel.