[openbeos] Re: A new BMessage implementation (Message4)
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 03 Nov 2005 15:55:27 +0100
[I sent the mail yesterday already, but missed, that sending failed. So
please excuse my repetition of arguments others have given in the meantime,
too.]
On 2005-11-02 at 19:23:25 [+0100], Michael Lotz wrote:
[...]
> > 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.
But it's even better not to copy them at all, isn't it? :-)
> I'll change that though.
Good. :-)
> > 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.
Not just settings files. WonderBrush for instance uses flattened BMessages
in its document format, other programs might use them, too. Since Haiku
will coexist with Zeta, I think, a default flattened format Zeta cannot
read wouldn't be a wise choice. I'm all for making both formats available
via others method, but the default should be the R5 format.
> > 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?
Neither is speed when flattening/unflattening a message to be written
to/read from disk.
> 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...
A few remarks, already:
* We should keep an eye on the performance of editing operations
(replacing, removing, adding not at the end). Since the item data buffer is
tightly packed (is it really?) those can be expensive. IIRC I sent you some
test implementing a sorting algorithm. Would be interesting to see how that
performs.
* It would be nice to implement lazy copy on write for messages (AFAIK Dano
does this). Especially in case of intra-app messaging we would be able to
safe a lot of operations, for often messages are created, sent and then
just deleted by the sender. If {Send,Post}Message() would just add a lazy
copy to the target looper, we had a zero-copy message delivery in this case.
* Dano uses shared memory to send big messages. This does, of course, work
best, if the message data are already stored in a flat single buffer. But I
suppose your three buffer design isn't that bad either for the task, since
for a big message we could send the message header and the field headers
through the port and use shared memory for the item data.
CU, Ingo
Other related posts:
