Date: Tue, 14 Nov 1995 09:42:59 GMT From: Andreas Viviani <aviviani@ACCESS.CH> Subject: List related bugs and dummy (tummi) bugs #2OK, and now to the real list bugs.
They are quite fascinating, because they come silently at night, you do not see them in your Beta version, and you first do not understand why your customers are so angry... ...they are REAL bugs! They even crack if you crush them.
The "problem" shows up only with big lists. Admittedly, the following was sent two months before or so, but the interest in lists on the LIST forces me to send this info again. There is a test movie associated which made its way through Macromedia (thanks, Alex!); I can send it to anyone requesting for it in a private mail to me (aviviani@access.ch)
Since big property lists get important in my ongoing project, I tested more, and got some "interesting" results on both platforms. In summary: I never had a case where a property could grow to the limit of physical memory available; in all cases, the movie or projector crashed or bucked long before.
If you prefer to test Lingo and do not like to read long email, order the movie.
A movie was created doing nothing more than creating property lists with an "endless" number of elements and property types of type number, string or symbol. The lists will look like
[1:1, 2:2, 3:3, 4:4, ...] with number properties ["N1":1, "N2":2, "N3":3, "N4":4, ...] with string properties [#N1:1, #N2:2, #N3:3, #N4:4, ...] with symbol propertiesIn the following table, there is listed how many elements (count()) could be filled into a property list type before things got odd:
-----------------------------------------------------------
number string symbol
------ ------ ------
speed of building: fast slow medium
memory requirement per element: medium big low
Windows Movie: ~38'000 347'979 ~4'000
error type occurring: 2 4 2
Macintosh Movie: 196'382 27'309 25'100
error type occurring: 3 5 1
-----------------------------------------------------------
error types: 1: "script error: operand expected"
2 "general protection error"
3: "The current movie has used all main memory"
(which never was true physically)
4: freezing
5: just like freezing, but continuing after ~50 seconds,
(Director was doing something like counting its legs)
then doing that again in chunks of ~25'000; veery slow,
after 5 hours, there were 100'000 elements.
testing machines: Macintosh Quadra 700 Sys 7.1 20MB RAM, Director 16MB
TARGA 486/66 Win 3.11 16MB RAM, virtual memory off
The results were obtained within Director; Projectors were comparable but
differed in the error type (error type 3 will turn to error type 1).
NOTA BENE: The movie does not much more than creating a long property list; so if there is a real movie with lots of globals, symbols and Lingo, results will go worse.
CONCLUSION: If you have a need for big property lists, think twice if you really need them or if it will be better to switch to an XObject managing dynamic arrays in C, or a file-based database.