On Sat Oct 3, 2009, Richard Gaskin ambassador at fourthworld.com wrote:
Maybe it meant "Too many for the IDE to display", since it seems the
engine is fine. :)
I wonder exactly what their threshold is for "too many", and how they
arrived at it when they wrote their IDE.
The more I played around with my tests, the more I see a very dramatic
difference in responsiveness beyond a certain threshold somewhere beyond
6,000 objects. I haven't yet pinned it down exactly, but definitely
10,000 is beyond acceptable for most uses, so it's somewhere between 6k
and 9k.
The difference between 6k and 9k objects is so dramatic that I have to
wonder if there's some aspect of how the engine's memory mapping or
object hashes were written that may play a role in the sharp performance
degradation.
I dunno. I just know not to try working with 9k objects. ;)
--
Richard Gaskin
Richard,
Back in 2004 we had a discussion on the improve-list very much about the
same problem. At that time The Rev-IDE was unable even to cope with
cards that contained around of 3000 objects. The Metacard IDE had no
problems with this. Creating a standalone in the Rev IDE lasted
"forever", again , no problem in the Metacard IDE.
Here is some of the relevant text on my "RevTestPage"
<http://www.sanke.org/RevtestPage> from 2005:
Revolution Test Stacks
Following the recent discussion about the "RevTable bug" (Bugzilla
2019) and Standalone Builder problems (Bugzilla 2217) on the
improve-revolution list (August/September, 2004) I add two stacks
<http://www.sanke.org/Software/RevTestStacks.zip>
and a readme file for interested testers of the Revolution IDE that
demonstrate the bugs and related problems with stacks that contain
larger number number of controls, especially larger number of fields.
Details - i.e. the complete bug reports of Bugzilla 2019 and 2217 -
are to be found by clicking the "readme"-buttons of the test stacks,
which however when opened in the Rev environment need some time to
display the contents of the connected field in the larger 3300-fields
stack that may bring down the Revolution IDE almost to freezing point
on medium-fast computers.
Read below what has been fixed in the meantime:
All the described problems do not appear when the stacks are opened in
the Metacard IDE. You can test this by downloading the Metacard IDE
(1.4 MB zipped) from here.
Thanks to the continued efforts to improve Revolution some of the
described problems have now been resolved with version 2.5.1. (March
2005). The speed of the test stack is now almost identical in both
environments with even a small advantage for Revolution - when run in
the development environment..
However, the problem of building a standalone of this stack
unfortunately has not dealt with successfully even with Revolution
version 2.6 (June 2005). Building the standalone in the Rev IDE takes
"forever", whereas building a standalone of the test stack with the
Metacard "Standalone Builder" takes less than a second. (see comments
in Bugzilla 2217).
Version 2.7-GM-1 of Revolution (February 2006) has also not yet
resolved this standalone-building problem.
Responding to your post, I have expanded my test stack of 2004 to now
containing 10000 (ten thousand) fields.
I will post the URL of the new test stack in my next post to this list.
Preliminary results of testing with the 10,000 fields' test stack:
Creating the 10000 fields takes around 200 seconds in the Rev IDE, 130
seconds in the MC IDE.
Deleting the 10000 fields in the Rev IDE takes 420 seconds in the Rev
IDE, 6 seconds in the MC IDE
The three buttons for creating color patterns need about 2.3 seconds in
the MC IDE, 3.5 seconds in the Rev IDE
When the 10000 fields have been created, the Rev IDE is very much
unresponsive, no Problems with the Metacard IDE (with the exception of
the Metacard "Control Bowser" which needs also more time to respond when
10000 fields are present)
I did not yet test to build standalones.
So far for now.
Best regards,
Wilhelm Sanke
Prof. emeritus
University of Kassel, Germany
Education/Educational Technology
<http://www.sanke.org/MetaMedia>
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
