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

[Igor Stasenko]

On 22 December 2010 05:27, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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
>

and since it uncompressed (because .bmp can't even compress the data)
it takes 1600*1200*3 = 5760000 bytes on disk!
Now try convert it to either PNG or JPEG and see the difference.
One of the reasons why this format are so slow, because reading 10x
times more data from hard disk
takes 10x  more time than reading 1x data and unpacking it.

> 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.
>
> Cheers,
>  - 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
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.