Debug app quit / Xojo resume "performance"

General
1

I work on the same project (Xojo 2014.r2) on two different machines (both on Mac OS 10.9.x)

On one machine when I quit my debug app, I’m back to a responsive Xojo practically instantly.

On the other one, it’s a 10-15 second wait between the app quitting (at least visibly) and Xojo becoming responsive again.

Now, machine 1 is somewhat faster than machine 2 but still…

Is there something I can to to help this?

2

do you have images in the project ?
do you have remote volumes mounted when working on one machine or the other ?

3

Hi Norman,

yes, beaucoup images

Also yes on remote volumes.

In fact, to be fair, on the slower machine the project is loaded from the other computer across a 1GB ethernet link. The debug destination is set to the local drive though. My thinking is that would affect build & run time (which is not noticeably different from the fast machine) but not the quit & get-back-to-work time…

So to summarize, it’s not really a fair comparison. The fast machine is a) faster and b) opening the project locally, whereas the slower machine is somewhat slower (hybrid drive rather than full SSD and a bit slower CPU) and opening the project across gig ethernet.

I was resigned to live with it until I worked on the faster machine and found the quit time was practically instantaneous.

4

That’ll probably do it since the slower machine has “slower” access to everything

5

ok… but why do I see it at the “tear down” stage?

The debug build is local so in theory all the heavy lifting is done by the time it launches. When it quits it communicates back to the IDE and then the IDE just deletes the debug build right? Is there something else it needs to do?

6

Well turn on activity monitor and sample it when you quit
Pretty sure its got to do with all those remote items (images are NOT copied locally, external items are not etc)

But sampling it will tell

7

OK, will do.

I also realized that I’m not a/b testing the problem effectively. I’ll copy the whole project over to the slower machine and see if the problem persists.

thanks

8

if you copy it you may have to reset the locations for images etc so they’re not referencing remote volumes

9

Just to follow up.

Copying the project over to the local drive definitely speeds up the quit time. It’s still a bit slower than the other machine but that’s probably a machine difference.

I’ll live with it for now… the workflow is still favorable.

thanks for your help

Steve

10

OK, I have an update for anyone who might be wondering about this problem.

Just before I upgraded to 2014r2.1 (from 2014r2) I realized that setting the Debug Destination to my local drive (SSD hybrid) was not sticking - not just after save/open but even just after clicking to a different view / pane. So it turns out that all debug builds were happening across the network on the shared drive and I had missed it.

After upgrading to 2014r2.1 I see that setting the Debug Destination now sticks and is obeyed. Debug builds now all occur on my local drive.

And the breakdown delay after quitting a debug session? gone.

Steve