Cosmin Prund wrote; >You say something about the "paged pool system memory heap" limiting >available memory to something as low as 491Mb... what is the "paged pool >system memory heap" and are you sure the limit is that low?
Chapter 7 on Memory Management in the Russinovich & Solomon Microsoft Windows Internals reference I gave in my last note describes the Windows memory manager in detail. It gives the limits I reported. If you open the Task Manager and click on the Performance tab, you can see the Paged Pool which is where Windows puts bitmaps and visual things. You'll see the total Kernel memory (the sum of the next two numbers), the paged and non-paged pool. Only the paged is significant for Windows bitmaps. In the Task Manager, you can also see that physical memory is usually much larger, although the maximum amount available to a user process is 2 GB unless the /3GB switch is used in boot.ini and you have 4 GB physical memory installed. There's surely an equivalent for 32 bit Vista, but I haven't looked for it. At the moment, the machine on which I'm writing this (a Dell 650 workstation running XP SP2) which has 2 GB of physical memory shown as 2.09 GB because the ATI display card shared area takes away some off the top, shows approx. 1.58 GB available physical memory, but only 409 MB of Kernel paged pool. If you run the API GlobalMemorySatus, you can test this within an application, although this API won't show the paged pool size. If you want all the gory details, you can use the Poolmon utility from Windows Support Tools if you have installed Checked Build version of Windows or run tests under Windows Server 2003 and the Platform SDK. >I've done a bit of experimenting on my own, using VirtualAlloc and >VirtualLock to see how much physical memory I can get out of my test >systems. Here are the results (the test procedure is available at the >end of this message for anyone interested). > >Virtual Machine running Windows XP with 2000 Mb of RAM (yes, 2000, not >2Gb). I was able to get 1441 Mb of RAM. > >Next I added as much RAM as VmWare allowd: I increases the RAM for the >XP machine to 2900 Mb, my test app was able to get 1442 Mb of RAM... so >it's not the available RAM that limits the amount of RAM I can allocate >in my Delphi 7 app. > >Physical machine running Windows Vista 64 with 4Gb of RAM, everything >else being "default" I was able to get 1483 Mb of RAM. > >Next I've done the following experiment. I opened Delphi's Project >Options and I set the absolute minimum for all of min stack size, max >stack size and image base (so I'd allow for the most available address >space in my app). Here are the "upgraded" test results: > >Win XP 2000 MB of RAM: I got 1442 Mb max buffer. A 1Mb change! >Win Vista 64 with 4Gb RAM: I got up to 1486 Mb max buffer. A 3Mb >increase, not much for all the trouble I went through. > >So there you have it, one may hope to load up to 1.4 Gb of stuff into a >standard Delphi 7 application. This amount might increase by 1Gb if the >Delphi application is marked as being able to handle "negative" >addresses - still 2.4 Gb of stuff is NOT much. And in my case, I tested >with a continuous, huge buffer - that's not typical. Although you can allocate the amount of available memory as shown in your example which gives results similar to those in the Task Manager, to use that memory for image processing, you would need to write an image handler to read a physical image file to load that memory and work on it there as a 2D array for each type of image you want to load. You could not use TBitmap to do this. You would also need to write a replacement for TCanvas. All that amounts to writing a replacement for Photoshop's very sophisticated tiled image memory manager, something on which I should not like to spend my time. For the moment in 32 bits, using memory mapped files for large images seems to me to be a simpler though slower solution, since one can get the TIEBitmap based software from HiComponents (Imageen) for a very reasonable price, but there is no Canvas when the images need them. I reported a work-around for this in my last note. As a test, I just opened two 20x20 K side length RGB color images (1.258 GB each) without alpha layer and read/write/erase projection transformation control point information to it with no noticeable speed loss in one of my applications which can be downloaded from: http://www.uni-koeln.de/~al001/percor.html Remaining available memory is only slightly reduced vs. the no image loaded state. Irwin Scollar _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
