You are not logged in.
Pages: 1
While mORMot is compiling using x32 compiler it's may be useful for us:
Q: I am using Windows x64 edition. How do I enable my applications to address more than 2GB RAM?
A: Add a line containing {$SetPEFlags $20} to the .dpr file. This will set the LARGE_ADDRESS_AWARE flag in the executable and Windows x64 will consequently give the process a full 4GB user address space instead of the usual 2GB.
Thank to FastMM4_FAQ.txt for this idea.
Delphi XE define const in Winapi.Windows for $20, and it's possible to write:
{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}
Offline
Do you need so much memory?
The SQLite3 engine makes little use of RAM during its activity.
The disk cache is how most of the buffering occurs, and indexes are to be created for faster access.
No part of the framework is memory-consuming, AFAIK.
The full regression tests uses very little memory (a few MB).
So I suppose that it could help in your particular case, which has some third-party components.
Thanks for the tip!
Offline
I create 2 thread per CPU core. On 24 (4 CPU x 6 core) server is 48 thread. So it 85Mb per thread. I use SpiderMonkey for Server-side business logic. SpiderMonkey Garbage Collection is hard operation, and I try to run it as late as possible for every thread, so lot of memory is good . (For example try to open 48 different tabs in FireFox and type about:memory in address bar - it's a 10-20Mb per tab - in my case - per connected client). Some client may in this time upload big(I support up to 10Mb) files, I use transformation for different type of file to HTML via user business logic for use it later as file preview - it's requires in-memory operation. Other client may create big (100 or more page) reports. For report generating and file upload is possible to use temporary files of course, but for SpiderMonkey and file transformation more memory=best performance.
Thanks for reply!
Offline
With such performance expectations, I understand that you'll have to reserve a lot of memory!
I suspect the memory manager itself may be a bottleneck with 48 threads.
FastMM4 has some performance issue with so many threads.
Did you try SynScaleMM? http://blog.synopse.info/post/2010/12/04/SynScaleMM
Within mORMot, we tried to avoid memory allocation as much as possible. It could help in your case, I suppose.
See http://blog.synopse.info/post/2011/05/2 … plications
Did you try to use DWS instead of JavaScript? It uses few memory, and is fast (in its latest release), even with no JIT.
Offline
I read your post about fast multi-thread Delphi applications as soon as found this site and use all you proposition!
I know about DWS, but I need the same language for client (browser) and server business logic, so SpiderMonkey is best for me.
SynScaleMM is ASAP to try.
Offline
Pages: 1