At Tue, 31 May 2011 23:16:12 +0200, Mariano Martinez Peck wrote:
On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima <yoshiki@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@vpri.org> wrote: > > 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.
Hmm, I'm also confused. You know that ByteStrings are padded in the image, right? And you see a user of #hackBits:, #nextWordsInto:, right? We can eliminate some buffer copying there. For example, when I run Fuel materializer, I see PositionableStream>>nextString is used which does not do basicNew: of (Byte)String but actually does extra copy (which can be easily eliminated and would make it faster). -- Yoshiki