Speed differences between the Metacard and Revolution IDEs

[Wilhelm Sanke]

After our recent discussion in the thread "10000 fields and crash" I
experimented with some of my larger stacks - that work absolutely fine
with Metacard - in the Rev IDE (Revolution 2.1).

I noticed that the buttons of a stack with about 3000 controls and 10 MB
size have a delay of about 4 seconds in the Rev IDE(Windows 98 with 800
MHz), i.e. when you click at a button they remain for 4 seconds in the
pressed-down state before returning to normal and executing the scripts.
Executing the scripts themselves shows no differences once they have
started. The buttons of the Rev IDE display the same slow behavior when
the large stack is loaded. Menu buttons are not effected.

I then tried to build a standalone under Rev to see if this button
behavior would go away.

To build a standalone of the 10 MB stack with Metacard took three
seconds. With the Rev Distribution Builder is seemed to take forever, so
I stopped this part of the experiment after half an hour and tried
smaller stacks.

Here the results for the smaller stacks:

- stack 113 K with 775 controls (one card)  50 seconds
- stack 180 K with 1546 controls (two cards) 2 minutes 30 seconds
- stack 268 K with 2300 controls (three cards) 6 minutes

Compiling these stacks under Metacard was one second only.

I then retried the 10 MB stack: Building the standalone with the Rev
Distribution Builder took 47 minutes! Most of this time - 38 minutes -
was needed for "removing development properties" and " setting Profile
options".

The exe-version of the 10 MB stack then behaved identically for both the
Metacard and Revolution versions without any delays when buttons are
clicked, which means that the reported slow speed is a result of the
more complcated structure of the Revolution IDE.

The relative slowness of the Rev IDE has also been reported several
times for other situations, too.

It seems that the Rev team still has a long way to go to achieve the
"classic" simplicity and speed of Metacard and to find an optimal
compromise between integrating their new features and maintaining an
acceptable speed of execution at the same time.

I will send a more detailed report to the improve-revolution list.

Regards,

Wilhelm Sanke