🚀 go-pugleaf

In article <310110c0.44581633@news.connectnet.com>, 
jtara@connectnet.com said:
>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.


  Well, I myself use HeapAlloc for the mempry calls.  HeapAlloc is 
smart in that it will use VirtualAlloc if necessary completely 
transparently.

>Are you sure that GlobalAlloc doesn't wind up calling
>

  You didnt finish this line.  I assume you mean GlobalAlloc doesn't 
wind up calling HeapAlloc?  As far as I understand GlobalAlloc still 
calls 16-bit memory rather than 32-bit memory.  I could be wrong, but 
in one of my Win32 books floating around here it states that Win95 
Explorer still uses GlobalAlloc to allocate memory for "Drag and Drop" 
data structures and that this is 16-bit RAM it is allocating.  It also 
states that GlobalAlloc is much slower than using HeapAlloc or 
VirtualAlloc.  I haven't tested this much, but it sure SEEMS slower 
when I switch HeapAlloc calls to GlobalAlloc.  Although this might be 
the power of suggestion. :)  However I've read this in more than one 
place so I'd just assume it was correct.

>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?

   Well, if reading it into RAM from the start isn't any faster than I 
don't think I'll get any speed benefit by converting it to a memory 
mapped file.  After all, its basically just converting file accesses to 
memory accesses.  I would think I'd end up with a little more overhead 
this way, although memory mapped files are certainly usesful.

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


  Whatever works is good enough I guess. :)  I find that my compilation 
is at least as fast as LView and noticeably faster for larger JPEG 
images.  Of course changing the DCT options makes a large difference.  
Incidently I don't notice any difference in image quality if I use 
floating point or slow integer DCT as opposed to fast integer.  Other 
than the significantly longer decompression times, there is barely any 
difference at all (that I can see) if there is one.  Is it the same on 
your end?  Perhaps my eyes are failing me. :)


           -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------