[Vm-dev] BMPReadWriterPlugin , do we really need it?

Andreas Raab andreas.raab at gmx.de
Wed Dec 22 04:27:04 UTC 2010

The only issue with BMPReadWriterPlugin was that for some reason the 
primitives weren't used. Probably an oversight on my behalf when I did 
the last Teleplace/Squeak sync. Fixed now.

Benchmarks: 1600x1200 24bpp image

[Form fromFileNamed: 'benchmark.bmp'] timeToRun.

Interpreter read:  1684 msecs
Cog read:          1158 msecs
Primitive read:     100 msecs

[BMPReadWriter putForm: f onFileNamed: 'benchmark.bmp'] timeToRun.

Interpreter write:  693 msecs
Cog write:          434 msecs
Primitive write:     32 msecs

So much for "just a bit" in speed. It's even more than I remembered[*].

[*] In particular considering that [Form extent: 1600 at 1200 depth: 32] 
timeToRun => 80 msecs. In other words the "real" performance difference 
is rather more along the lines of 50x in the actual code.

   - Andreas

On 12/21/2010 7:41 PM, Andreas Raab wrote:
> On 12/21/2010 2:33 PM, Igor Stasenko wrote:
>> i just stumbled over it, and i thought that today, we don't really
>> need such kind of cruft.
> This ain't cruft. This is a 10x performance boost (even over Cog).
>> It is just a two methods, and there is nothing essential, in it.
> The plugin is absolutely essential for high-performance reading of
> standard 24bpp BMP files.
>> And i think that .bmp image format is really crappy format, which no
>> one using today,
> Very funny. Spoken like a true Macvocate. Outside of academics PCs still
> play a pretty important role, and on Windows, BMP files are still the
> standard.
>> and given that we got Cog, it could run just a bit slower, if
>> implemented in image w/o primitives.
> Right. "Just a bit". 10x.
> Cheers,
> - Andreas

More information about the Vm-dev mailing list