|
|
"static" and object methods
At 16:09 16.01.2003 +0000, Paul Lemon wrote on direct-l:
<quote>
The code gets duplicated for each instance, however the code is stored in
the lingo "bytecode" format which will be smaller than the actual text of
your script - I'm not sure how much smaller the byte code is though.
You can check that the code is duplicated by creating a parent script
"testObj"
</quote>
<snip>
Paul,
I'm not convinced that your test prooves that indeed the code gets
duplicated for each instance. Your example prooves that
1. Lingo won't modify existing instances if the scripttext of their parent
is modified
2. Lingo creates an object according to the new scripttext of its parent
script, if this has been modified/recompiled
I think Lingo creates a new bytecode representation of a script when it
recompiles. Removing the old one is left for the garbage collection so the
old bytecode won't be deleted as long there still exists a reference to it.
Any instance holds a reference.
Well, lets assume you are right and the code gets duplicated for each
instance. Even if it's bytecode we would have to expect the additional use
of memory per instance to be in proportion with the lines of code of the
parent script.
On the other hand, if every new instance just gets a pointer to the memory
address of the bytecode, instanciating a tiny or a huge parent script
should eat about the same (disregarding properties here).
So I tested with 2 different parent scripts:
Script "bigObj" has 1013 lines of code, 1 property which is a symbol.
Script "smallObj" is the very minimum possible, the scripttext consists of
one line of comment only
--
(adding an "on new" handler is only good style or rather allows the author
to add his own code to the new() which Lingo handles by its own.)
my test:
--------- movie script ----------
on testInstances dNum
-- big
dL = []
free1 = the freebytes
repeat with index = 1 to dNum
dL.append( (script "bigObj").new() )
end repeat
used = free1 - the freebytes
dMsg = dNum && "instances of bigObj took about" && used && \
"bytes, about" && used*1.0 / dNum && "each."
put dMsg
-- small
dL = []
free1 = the freebytes
repeat with index = 1 to dNum
dL.append( (script "smallObj").new() )
end repeat
used = free1 - the freebytes
dMsg = dNum && "instances of smallObj took about" && used && \
"bytes, about" && used*1.0 / dNum && "each."
put dMsg
end
------- EoS -----------
And I got theese results:
testInstances 10
-- "10 instances of bigObj took about 1156 bytes, about 115.6000 each."
-- "10 instances of smallObj took about 1240 bytes, about 124.0000 each."
testInstances 100
-- "100 instances of bigObj took about 12392 bytes, about 123.9200 each."
-- "100 instances of smallObj took about 12392 bytes, about 123.9200 each."
testInstances 1000
-- "1000 instances of bigObj took about 120632 bytes, about 120.6320 each."
-- "1000 instances of smallObj took about 120632 bytes, about 120.6320 each."
testInstances 10000
-- "10000 instances of bigObj took about 1216620 bytes, about 121.6620 each."
-- "10000 instances of smallObj took about 1216964 bytes, about 121.6964 each."
Those results don't look like the use of memory is in proportion with the
amount of code of the parent.
Caveat: the freebytes are not really reliable on windows since win memory
managment isn't mac-ish but pages "fresh" memory if needed. If that
happens, suddenly all those instances seem to have used a negative amount
of memory. On my machine results started to look funny if I tested with
more than 13000 instances. YMMV
best regards
Daniel Plaenitz
|
