Hi Przemek, On 2009 Nov 20, at 14:29, Przemysław Czerpak wrote:
> On Fri, 20 Nov 2009, Szak�ts Viktor wrote: > > Hi, > >> I'd say go for it. > > I'll commit it in a while. Thank you, I saw you did it since. >> Any reason we don't seem to have HB_FM_DLMT_ALLOC >> enabled by default when building vmmt lib? I think >> we should enable it. > > For all platforms which now uses DLMALLOC I think it can be enabled. > For sure for 64bit builds. Using many mspaces on 32bit platforms may > cause memory fragmentation. For 99% of programs it should not be a > problem but if someone created code which allocates very large memory > blocks containg hundreds of megabytes then it may create problems. > On 64bit platforms the address space is large enough to fully eliminate > this problem. > There is also yet another problem with DLMALLOC. Valgrind does not > recognize it so it cannot create some memory statistics when it's used > instead of default memory manager which is replaced dynamically by > valgrind. It means that for Linux it should be optional. > Anyhow I've just made some test with suse11.2-...@64 and DLMALLOC > compiled with hvmall.c is noticeable faster then default memory > manager and speed difference is quite huge (~15% in speedtst.prg). > so in some cases it can be important extension for final code. Well, pls feel free to decide, to me, from your words it seems it can be enabled for win/os2 platforms without any restrictions. For "valgrind platforms", IMO we may also enable it by default and disable it for debug builds only, since I believe the latter is typically used for valgrind testing. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
