search

andremussche / scalemm

Fast scaling memory manager for Delphi
https://code.google.com/p/scalemm/
Other
98 stars 22 forks source link

W1023 Comparing signed and unsigned types - widened both operands (Delphi) #23

Closed Zeus64 closed 8 years ago

Zeus64 commented 8 years ago

on xe4, when i try to use scalemm2 i have this warning

W1023 Comparing signed and unsigned types - widened both operands (Delphi)

here:

procedure WriteNativeUIntToHexBuf(hFile: THandle; ANum: NativeUInt; aDigits: Integer = 8); .. var LCount: Cardinal; .. while LCount < aDigits do

thanks by advance stéphane

andremussche commented 8 years ago

thanks, it's fixed now (btw: it was only in a debug write to file routine)

Zeus64 commented 8 years ago

:) i m working with scaleMM now .. by the way what is exactly the difference between scalemm2 and scalemm3 ? can i really use scalemm2 in production server?

andremussche commented 8 years ago

scalemm3 is/was a experimental version with a complete different approach, however in practice the speed was too slow

scalemm2 is used in production by some users, but there is in some circumstances a "live leak" when you have a lot of interthread memory: so when you allocate a lot of string/objects/arrays in thread 1 and pass these to thread 2 (for calculation etc) and free them in thread 2: the memory belongs to thread 1 but when thread 1 is not active it won't release the memory

2015-11-03 10:10 GMT+01:00 loki5100 notifications@github.com:

:) i m working with scaleMM now .. by the way what is exactly the difference between scalemm2 and scalemm3 ? can i really use scalemm2 in production server?

— Reply to this email directly or view it on GitHub https://github.com/andremussche/scalemm/issues/23#issuecomment-153293552 .

Zeus64 commented 8 years ago

aah ok, i guess this is not really a bug, but the way scalemm work no? it's like to know that scaleMM use more memory than fastmm. Or this memory in thread1 is lost and can not be reused in anyway by thread1 ?

andremussche commented 8 years ago

no, it is not OK when the memory is "never" released (or at least not in time) so you get out of memory, so you should test first if you encounter this bug or not (special circumstance)

and yes: because you have a memory pool PER thread it uses more memory

2015-11-03 12:17 GMT+01:00 loki5100 notifications@github.com:

aah ok, i guess this is not really a bug, but the way scalemm work no? it's like to know that scaleMM use more memory than fastmm. Or this memory in thread1 is lost and can not be reused in anyway by thread1 ?

— Reply to this email directly or view it on GitHub https://github.com/andremussche/scalemm/issues/23#issuecomment-153320321 .

Zeus64 commented 8 years ago

i will do lot of test now on it, and even put it on production server ... we will see!

Zeus64 commented 8 years ago

one problem is that when we debug, we must use Fastmm because of the warming about memory leak (very usefull), and we can use only scalemm in production, that make more complicated to see bug in real time