[Esug-list] ESUG SummerTalk - Fuel, binary object serializer
Mariano Martinez Peck
marianopeck at gmail.com
Tue May 31 17:16:12 EDT 2011
On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
> At Sun, 29 May 2011 20:52:45 +0200,
> Mariano Martinez Peck wrote:
> > On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima <yoshiki at vpri.org>
> > At Sat, 28 May 2011 09:33:27 +0200,
> > Stéphane Ducasse wrote:
> > >
> > > Yoshiki
> > >
> > > if you want to help testing, improving fuel you are welcome.
> > > The idea is to make it fast fast fast without vm support.
> > Yeah. The reason for example I went to pad data to 4 bytes
> > What do you mean by padding data to 4 bytes? I don't understand :(
> Say a string has length of 5 ('abcde'), the data in file for it
> would be "97 98 99 100 101 0 0 0".
Sorry but I don't understand then how that is related to "The reason for
example I went to pad data to 4 bytes was that
there may be a clever trick I may be able to do to read data into
arrays "directly" and stuff, but did not get around implementing it."
> > was that
> > there may be a clever trick I may be able to do to read data into
> > arrays "directly" and stuff,
> > what do you mean by that? like ImageSegment does? I mean, include also
> object headers in the stream and then avoid to recreate objects (using
> #basicNew) ?
> Not like ImageSegment, but more like #hackBits: reading from file
> into a string object of right size.
I am not sure if I understand. For some kind of objects (those that are
variable) we store first its size and then at materialization time we
directly create an object of that size using #basicNew:
but I guess you are talking about something else.
> For pointer arrays and actual
> literal fields, I am not sure I can apply this however.
> I would not put object headers, as you would agree^^;
> -- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esug-list