Performance Issues On Linux

Richard Gaskin ambassador at
Sat Feb 12 16:21:55 EST 2011

David C. wrote:
> I have a stack in development that uses a really large amount of
> persistent textual data, which I would normally store outside of the
> stack...
> Functionality can be described as:
> mouseUp on a control, display text file
> mouseUp on a different control, display different file
> (not rocket science, right?) ;-)
> Out of curiosity, I decided to add all of the nearly 80 text files
> (roughly 8MB) directly into the stack itself, just to see how well it
> would work and was both surprised and disappointed with the results.
> On Windows and Mac, the bloated stack works just fine! On Linux
> however, it takes sometime 3 to 4 minutes to load up and display
> itself on the screen. I can literally watch it gulping MB after MB of
> memory using the system monitor, then it will finally display.
> When running as a standalone in Linux, it will not display on the
> screen until it reaches the point where it's using around 85MB of ram
> memory. In the IDE on Linux, it takes around 100MB of ram before
> either the IDE or stack is displayed.
> I also have a different stack containing around 130 small graphics and
> have noticed a very similar negative performance issue when
> using/updating them in Linux. Windows and Mac update the screen almost
> instantaneously, where even with the screen locked, you can almost see
> each one being updated individually on Linux. Very noticeable in
> comparison for both issues.
> With all factors being exactly the same, does anyone have any ideas as
> to why I'm seeing such a negative performance differences on Linux?

8MB isn't very big.  I've tested stacks with more than 100MB of custom 
prop data, and while it can sometimes take a few seconds to load it 
never takes minutes.

Is the data stored in props or fields?

Also, what are the specs on your system (CPU, RAM, OS, etc.)?

   Richard Gaskin
   Fourth World
   LiveCode training and consulting:
   Webzine for LiveCode developers:
   LiveCode Journal blog:

More information about the Use-livecode mailing list