Re: [gmime-devel] Mapping MIME parts to byte offsets

[Jeffrey Stedfast <fejj novell com>]

Alex Hudson wrote:
> Hey,
>
> Jeffrey Stedfast wrote:
>> Instead of storing header offsets on the GMimeHeaderList, we now store a
>> substream of the input stream that was fed to the parser (which has the
>> offsets).
>>   
>
> So instead of values being stored, we grab the substream, reset it to
> find the start and then ask it for the length?

Or you can look at the bound_start and bound_end members on stream and
do the math :-)

I think g_mime_stream_length(), depending on the stream type, might be
more expensive as it might actually do the disk seeks. I'd have to check
to be sure. Or maybe it only does the seek if the bound_end is -1 (which
wouldn't happen in the cases we're talking about here since the parser
will set absolute bounds).

>
> Seems fine to me; actually having a handy GMimeStream into each block
> of interest is theoretically quite useful - and if the headers aren't
> duplicated I would be expecting some kind of memory saving (and
> possibly speed) too.

Definitely a memory savings (a GMimeStreamFs is probably about 36-48 (I
forget how many bytes a GObject takes up) bytes in memory vs >= 1 KB, so
yea - potentially quite a lot of memory savings). Not sure about
performance. The realloc overhead (for the parser's internal buffer)
from past experimentation seemed negligible, but the strdup()'s of that
internal buffer might add up quickly (I'd have to do some profiling to
know for certain).

Glad you approve of this clever solution ;-)

I did, however, think of a bug in it last night... if you change the top
level mime part's headers and write the message to disk, I suspect that
it won't reflect the changes because the message will write out the
cached stream. Easy fix and not something I expect you'd have to worry
about in Bongo.

Jeff