Op Mon, 01 Apr 2013 10:34:06 +0200 schreef Wolfgang Lenerz
<w...@wlenerz.com>:
Hi all,
I have a problem with Qliberator.
Consider the following program :
100 DEFine PROCedure increase_result_array
110 LOCal dim1,dim2,temparray$(0,0)
120 dim1=DIMN(result$,1)
130 dim2=DIMN(result$,2)
140 DIM temparray$(dim1,dim2)
150 REMark arrcopy result$,temparray$
160 DIM result$(dim1+100,dim2)
170 REMark arrcopy temparray$,result$
180 DIM temparray$(0)
190 END DEFine increase_result_array
200 :
210 DEFine PROCedure p
220 LOCal lp%
230 DIM result$(1,40)
240 FOR lp%=1 TO 90
250 increase_result_array
260 END FOR lp%
270 END DEFine p
280 :
290 p
295 CLS
300 PRINT DIMN(result$,1)
310 kk$=INKEY$(-1)
What is does is call the increase_result_array times, each time the
result$ array is increased by 100 elements (I've r'mmed out the parts
where the old array is copied to tthe new one and back)..
The resulting array will have 9001 elements, 40 chars long each.
When I run this in S, this Sbasic job occupies about 640 K (240 were
already occupied before running the prog, e.g. for the screen etc).
OK, seems normal.
If I compile & execute this, the resulting Qliberated job takes a
whopping 32 MB!
It seems to me that there is a bug in the variable
allocation/deallocation routines.
Can anybody confirm this? More importantly, does anybody know a way
around this?
Wolfgang
Oh, and,seeing today's date, I hasten to add that this is no joke...
I am not laughing and can confirm your findings.
(On QDOS/SGC it ran out of heap space.)
ReDIMensioning to zero first doesn't help either.
The Qlib manual states that ReDIMensioning "is a fast way of clearing all
elements to zero".
While Jan Jones in her book talks of "releasing the old before assigning
the new one".
This may explain why SuQcess may grow to several MiB's, because a lot of
ReDIMming is done there too.
As Qlib uses its own name table this must be a Qlib feature.
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
