Weird speed problem

[Tereza Snyder]

On Aug 20, 2012, at 10:05 AM, Lars Brehmer wrote:

> I am looking for tips on how to solve a strange problem I am having.
> 
> I have two very similar stacks that are behaving very differently speed wise.
> 
…
> The stacks are very similar - the faster one is based entirely on the older one! What could be wrong here?
> 
> RunRev 2.8
> iMac, Snow Leopard, 2.4 GHz Core 2 Duo
> 
> Anyone have an idea for me to try? There is nothing in these stacks that is particulary complex or cpu intensive. Lots of interface elements that are buttons with icons from the image stack. No heavy code, lots of buttons with short scripts, stack scripts with maybe 1000 lines and a few dozen handlers some of the buttons call up, etc. And once the slow one is loaded, it does everything just as fast as the other one, practically instaneous. The main difference is the slow one uses unicode, but I am not aware of performance issues storing unicode text in custom properties, and when the stack opens, it doesn't access any of the data anyway.


Hi Lars,

You’re 'lucky’ that the problem is visible in the IDE. I have a few strategies to suggest that you’ve probably tried already:

-- Is there a script running during the long delay? Can you isolate it by commenting out most or all of your initialization in both projects, running your timing tests, then selectively restoring functionality until the delay reappears? Once you finger the culprit process, you can tinker with it. 

-- Replace some or all of your resources with dummy data to see if that’s the problem.

-- Anything happening on the screen? is it locked? 

-- RunRev 2.8 was a nice stable release, but now outdated. Could you try a more recent version and see if it makes a difference? IIRC, unicode support has changed a lot since 2.8.

Believe me I know what it’s like to suffer through a mystery like this. To me the key has always been isolation of the problem. Try to pare everything away from a test version of the project until you have the minimum configuration that still has the error. At some point during the process, the culprit will show up in all its ugly glory. If you’re 'lucky', it will be a subtle sneaky bug -- with an easy fix -- that no one could have anticipated. On the other hand, it might be a head-slappingly obvious error you’ll be ashamed to confess. I once spent a week or so on a terrible bug that was due to a missing semicolon (in C++).

good luck,

t