En/na Micha Nelissen ha escrit:
Luca Olivetti wrote:
Seeing this thread, I used GetFPCHeapStatus and, effectively,
CurrHeapSize is growing but CurrHeapUsed isn't, so apparently
TJpegImage.LoadFromStream (that's what I'm using) causes heap
fragmentation.
Can you reproduce this in a small test
Luca Olivetti wrote:
Seeing this thread, I used GetFPCHeapStatus and, effectively,
CurrHeapSize is growing but CurrHeapUsed isn't, so apparently
TJpegImage.LoadFromStream (that's what I'm using) causes heap
fragmentation.
Can you reproduce this in a small test program? Perhaps there is a
sim
On 11 May 2009, at 12:00, Luca Olivetti wrote:
Is there any undesirable side effect due to the use of cmem?
It's usually slower if you perform many allocations and deallocations
of small blocks. Other than that, no.
Jonas
___
fpc-pascal maillis
En/na Jonas Maebe ha escrit:
[sorry to revive an old thread, but I'm having a similar problem and I
prefer to follow-up than to start a new thread. Since it's old, I'm
quoting it without trimming]
On 14 Jan 2009, at 13:02, Burkhard Carstens wrote:
Am Mittwoch, 14. Januar 2009 04:50 schrie
On 14 Jan 2009, at 13:02, Burkhard Carstens wrote:
Am Mittwoch, 14. Januar 2009 04:50 schrieb Seth Grover:
I had the same problem. You could try to enable "BESTMATCH" in the
heap
manager by either compiling the rtl with "-dBESTMATCH" or changing
"{ define BESTMATCH}" to "{$define BESTMATCH
Am Mittwoch, 14. Januar 2009 04:50 schrieb Seth Grover:
> I've got a fairly large system (originally written in Delphi, then
> moved to Kylix, and now finally in FPC 2.2.2) which is doing a lot of
> different things. Various threads are running which execute reports,
> communiate with other devices
I've got a fairly large system (originally written in Delphi, then
moved to Kylix, and now finally in FPC 2.2.2) which is doing a lot of
different things. Various threads are running which execute reports,
communiate with other devices, query data, process notifications, send
and receive data on so
