🚀 go-pugleaf

fortunat@interpath.com (Jumpstile Turner) wrote:

> Incidently, malloc() and free() are measureably slower under 
>Windows 95.  These generate calls to GlobalAlloc which are still in the 
>Win32 API just for compatability. Under Win32 you want to use HeapAlloc 
>or VirtualAlloc if you can.  

I'm not sure that using VirtualAlloc() would be such a good idea,
except for large blocks. malloc() and free() grab large blocks and
then divvy them up, so most of the time when you call malloc() it
doesn't actually go out to the operating system and allocate anything.

Are you sure that GlobalAlloc doesn't wind up calling

>I've also been looking at sucking the JPG 
>files into RAM and decoding them from ram because JPG's tend to be 
>rather small while they're compressed. I'm not sure if I'll gain any 
>speed benefit from doing so yet. 

The IJG library can make use of the ability to "back up" in the file -
that way, it can avoid allocating some buffers in some cases. Not sure
if this really gains you much.

Rather than sucking the files into RAM, though, why not just
memory-map the file?

In my app, I bring the JPG in and out through a CArchive, which
precludes direct access to the file (I could be serializing from/to a
CSocket, for example) and backing up. This would be a case for sucking
it into memory first, IF there is a significant advantage to being
able to back up.

Right now, though, I'm perfectly happy with malloc() for allocation
and letting the default MFC code (in CDocument) read the file for me.
It seems significantly faster than Lview Pro (not sure why - I have
the 32 bit version - is it not using the IJG code?) so I'm happy.
 

________________________________________________________________________
jtara@live.net  A new video clip (Netscape 1.1+) of San Diego Bay every half hour:
 <URL:http://live.net/sandiego/> Rated top 5% & "best 1000" by Point Communications