All of a sudden a project that used to take 20-30 seconds to run in debug mode is now taking 3 minutes or more. Is there a way to rebuild a project (easily) in the event that this project has become cluttered? Any other reason we’d see this behavior?
Here’s a little more information that may help resolve this.
When I click the RUN button, it shows that it is “Assembling code of pp_GN” which is a class. Takes about 1 minute to do that, then it shows a message “Assembling code for wExportFMData” which is a window. Then after approximately another minute or more, it will start the “compile” cycle and go through all the objects, which takes just a few seconds if I’ve previously run the project with no changes. This is driving me nuts, because it would normally just start the “compile” cycle and I wouldn’t see the "Assembling … " messages at all. I’m running the latest build 2015r4 on El Capitan.
OK, I found the problem - it’s 2015r4.
I opened xoxo 2015r2.4 and click the run button… “Assembling…” popped up for a second and it immediately went to the compiling process which it completed normally and in a normal amount of time. I’ve been using 2015r2.4 ever since it came out and compiling applications on a daily basis. We just switched to 2015r4 within the last week or two and this is the first time I’ve worked in this particular application since we upgraded. It is by far our largest application.
For now, I’m sticking with 2015r2.4 because 2015r4 takes at least 3 or 4 times longer to run this application. That’s lost time I can not afford.
Anyone else experience this behavior with 2015r4?
may be it’s a 64 bits compile ? these takes a longer time .
64 bits would not “run” on the debugger.
I think this is “normal” with 2015r4. All of my Projects now need muuuuuuch longer to compile (32&64bit).
One of my other developers said he switched back to r2.4 because the remote debugger was not working in r4.
The compile times in r4 are crazy long… I could grow old waiting for them.
Beware that this may lead to loss
There are things, like the new file types editor, that old versions WILL drop data from because they have no idea what all the new bits are for
Any new properties will suffer the same fate
Between 2015r3 and r4 and versions older than that you can be fairly sure something will get dropped going back & forth
And, the thing that is contributing to debug runs being slower in 2015r3 and 2015r4 is the IDE & compiler being more correct in how they handle enumerated values that are not just integer types underlying them. Something older versions dont do quite right.
Norman
I can appreciate that the compiler is being more intelligent about what it’s doing, but the difference in compile times is not just a few seconds, we’re talking multiple times slower. There must be more to it than that?
We have some smaller projects that we didn’t notice it as much, but this is our signature product and we make updates on a regular basis. This is a HUGE detriment to our development efforts because of the time we spend just watching it compile. And we’re on the latest and fastest Macbook Pro’s.
You have to be able to offer more than that?
If I put out an update and told my users that it’s now doing something more correct than it did before, but it takes 3 times longer to do it, we’d never hear the end of it.
Not sure why I [quote=238824:@John Fatte]have to be able to offer more than that?[/quote] when that is the truth
As my users often tell me, that is not an acceptable reply when you’ve just reduced my productivity.
We are looking into ways to improve the run-to-run speed on very large projects, but as usual- we can’t guarantee what we’ll be able to do.