Newsgroups: comp.windows.ms
Path: utzoo!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!il
From: il@csri.toronto.edu (Indra Laksono)
Subject: PM is Slow (WAS: Why Not PM?)
Message-ID: <8905250310.AA01586@yorkville.csri.toronto.edu>
Organization: University of Toronto, CSRI
References: <4316@sybase.sybase.com>
Date: Wed, 24 May 89 23:10:58 EDT


The company I work for is developing a product under PM and OS/2.
On an Apricot 386 with 4 MB, the performance of programs written
for PM has been surprisingly slow.  On one example, I had to simply
display a 1024x800 bitmap into a 512x400 window.  It took four
seconds if I use GpiBitBlt, but only requires < 2 secs if I shrinked
the image into a 512x400 image first.  If I use a very rough estimate
by knocking out all even bytes and even rows, the screen update is
immediate (<1sec).  Of course, the ratio of 1/2 means I had it easy,
but GpiBitBlt could have checked for easy 'squeezing' and taken
appropriate action.

Somehow, I have the idea that many parts of PM could still be
improved to gain performance improvements of several orders of
magnitude.

Other than that, it is a reasonably nice environment to work in.

Warning though: if you think that the 64K segment problems has
gone away with 286 OS/2, think again.  Using bit arrays is at
best Kludgy.
Example::
    With DosAllocHuge, you can allocate lots of mem to a huge
    pointer, but there is not much that you can do at the high
    level with this array.  We have DosOpen, DosRead, (or fread
    at a slightly lower level), but there was NO DIRECT WAY to
    say: read a large bitmap from disk.  You have to loop through
    and do getc (char by char), this not too bad if we consider
    that the os is smart enough to keep a buffer, but is not very
    elegant.

However, I like it, despite the shortcomings.