Hello Simon, Thursday, April 21, 2005, 1:57:20 PM, you wrote:
SM> On 20 April 2005 15:56, Bulat Ziganshin wrote: >>>> 1) can you add disableGC and enableGC procedures? this can >>>> significantly improve performance in some cases SM> I see (I think). Unfortunately currently the size of the allocation SM> area is fixed after a GC, so you'll have to change the code in the SM> runtime to keep allocating more blocks for the nursery. so that it is either impossible or too hard, as i understand you? >> i don't see resons why this can be slower. we will be a "good >> citizens" - return memory what is not used at current moment and >> reallocate memory when needed. SM> It might be slower because it involves extra calls to the kernel to SM> free/allocate memory, and the kernel has to update its page tables. it is very fast, at least in my win xp (120 thousands of 1-mbyte blocks are unmapped/mapped in one second! you can try yourself included program). the real problem is that windows goes to 0'ize all the memory it returns to our program so, the best solution, i think, will be current one + madvise for systems that supports it + one small but major change: current code switches to compacting when more than 30% of RtsFlags.GcFlags.maxHeapSize is used. it must calculate 30% of PHYSICAL memory while maxHeapSize is developed to limit VIRTUAL memory usage -- Best regards, Bulat mailto:[EMAIL PROTECTED]
map-unmap.cpp
Description: Binary data
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users