A couple of days ago the 1608 upgrade (Anniversary Upgrade) was forced down on my computer. After this I have noticed that Xojo 2016r2 is much slower than before and that Windows constantly displays the “Application not responding” window. Simple tasks such as switching between tabs in the IDE could cause this.
With the 1511 version of Windows 10, no problems at all.
I have updated all relevant drivers (graphics, network, chipset). I have 16GB of RAM and Xojo is not eating RAM nor CPU, it’s just “not responding”.
Anyone else seen this?
I see the same here. Apparently, Windows 10 AU is more sensitive than before to long events. I see the non responding in particular at compile time.
I’m running 1607 & Xojo is running just fine. As far as I can tell this is the anniversary edition - build 14393.10.
And as Mattias said: “the upgrade was forced down to his computer”. Unacceptable . Think now it’s time to do some research on how MS can be stopped from doing things with users’ machines unattended.
Even when I am traveling Windows 10 is trying to download stuff via my 4G hotspot.
For Xojo projexts I am still on Win7.
You know that you can configure a WiFi network as “Metered” to prevent Windows 8, 8.1 and 10 to download updates? I have it on for my iPhone and my 4G in the country house.
Settings > Update & security > Windows Update > Advanced options > Defer feature updates.
I am also noticing it in Firefox when I turn on my development tools. Hopefully there will be a fix soon (automatically downloaded to my computer of course )
Settings > Update & security > Recovery > Go back to an earlier build.
I have done that on one of my laptops… I will never do that again…
Go back to an earlier build = from 1607 back to 1151.
Sorry, but I don’t think this is much Windows itself fault, but rather old code with too long execution in a single event holding the system.
OS X Yosemite and El Capitan are exactly the same : any operation that takes too long and could freeze the system makes the beachball appear. For instance, Thunderbird does a lot of stuff at startup that apparently happen in a single event, and the beachball shows up for a good 15 seconds.
To some extent, Windows 8.x already did that for really long events ; it seems they have simply narrowed the cut off time.
Don’t forget that Windows 10 is also designed to support phones just the same as iOS, and just the same, any app holding the system is just as bad form.
That means code will have to be optimized even better. In particular, long tight loops will have to be forgotten for good.
I suppose 2016r2.1 doesn’t make this better, either?
I don’t think this problem is from Xojo side. If it is, then I would have experience it but I did not.
Yes, I understand. However, the downgrade forced me to reinstall Windows 10 completely on my Surface (irony!) as it went into a reboot-loop after going back from 1608 to an earlier build.
Downloading 2016r2.1 just now.
Actually, it looks as if 2015R4.1 is way faster and does not create the “Application not responding” during compile.
I had this same issue in 2016r1. I reverted back to 2015R4.1 and am using that. I am hesitant to upgrade at this point. Supposedly it was fixed in 16r2, but I did not test. I found the more controls that are in the project the slower the IDE was. This was the issue I was having and how to duplicate it (not sure if it is related to what OP is dealing with):