Op Mon, 01 Apr 2013 15:08:06 +0200 schreef Wolfgang Lenerz
<w...@wlenerz.com>:
Qlib can only claim 512K of heap, confirmed by the STATS.
Err, no. The 32 MB are definitely on the heap.
What I meant is that the $$heap directive only goes to 512K.
Qlib will obviously claim more if needed.
I tweaked your program a bit, disregarding what you tried to do for now.
The called Proc returns with a new dimension value and the reDIM is done
within the P loop.
This behaves differently!
VERY strange!
After the Inkey$, STATS reports: "Data: 524288 0 0 Stack: 800 172"
WHat about looking at the mem used when the prog is waiting for the
inkey (with the QPAC jobs menu?)
Before clicking STATS, Qpac2's JOBS reports: "memory used: 761680"
A much more sensible value.
There is no significant difference between before "inkey$" or after.
(After it's 432 bytes more!)
FORGET THE ABOVE RESULT.
I tweaked the basic again and could not repeat this result because the
original was lost.
There must have been a mistake, so I reconstructed it and now come to
about 9.15MiB (JOBS).
The changes suggested by George result in 12.69MiB, still a lot but less
then the original.
If we believe that Qlib keeps the old space before allocating new, this
explains my first test that claimed 34MiB.
Adding all the dim1+100's together comes to 409590, times 42 bytes for
each string is 17MiB.
Twice that for result$ and temparray$ does explain this 34MiB.
But how can we explain the 9.15MiB and 12.69MiB?
The last dimmed array (9001,40) is only about 380KiB, so 760KiB if we
include temparray$.
Could it be that Qlib behaves differently beyond its original boundary of
512KiB?
Bob
--
The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
