Poor C2 Editor Performance On Larger Projects

Bugs will be moved here once resolved.

Post » Mon Jan 15, 2018 4:46 pm

@humanescape has been helpful so far by providing workarounds, maintaining the thread and collecting data from people to find out what this is about.

I believe there's some level of misunderstanding which is causing some to get riled up. Nuance is hard for some to read, so please don't assume there's "blame" or "trolling" or any kind of ill will when someone's actions show they're doing their best to HELP.

People already pointed at win10 updates being a probable root cause way early on the thread, so I don't get why there's so persistent bickering about it. A change in Windows is the probable cause, get over it, it's still a problem that exists. It sucks for scirra as much as it sucks for us users.

So to keep the wagon moving:
While workarounds have decreased the issue somewhat for me, it's not completely gone.
Ashley reported 1 second to open the dialog, which means he can reproduce the problem.

To make it easier to debug, I have reduced an earlier example to a state that has the minimal amount of excess, while still showing the problem.
This capx only has a 1000 objects and some families, nothing else, while also consistently showing 1 second to open when clicking "add event"
https://www.dropbox.com/s/cm0dildivgcf6 ... .capx?dl=0

I've spent years dedicated to a project that is now suffering due to this, and I'm not the only one. (count on first post shows 14 users)
B
30
S
6
Posts: 79
Reputation: 1,618

Post » Mon Jan 15, 2018 5:13 pm

@huZba, sadly, it looks like it is not a specific Windows 10 Update that causes it, but yet the original Windows 10. I have gotten user reports that Windows 10 stock has the same issue. I have not confirmed myself (honestly, it would take me a long time to setup a VM for this and it won't really help the bug report I don't think).

I believe it is fair to assume for now, the bug existed since the initial Release of Windows 10.

But you are right, in either case. The real question is why is it happening. And, is there a fix or workaround. If it is Windows 10, why is it windows 10? Is it how C2 draws things? Is there a fix for it? What changes are involved and how intensive. Is it a 10 minute fix, or 1,000 hour fix? All of this needs to be determined. It would be fully reasonable if the exact root cause was found and announced, and if it is a 1000 hour fix then simply say it is too large to fix and explain why (these types of details might help people build their own workarounds). It is what it is. Or, if it turns out to be a quick fix, yeehaaa everyone is happy. But in order for that to happen, the exact root cause needs to be determined (to the level of knowing exactly what needs to be fixed/changed/patched). Everything else is a mute point.

Also, thanks for the sample CAPX. Much appreciated :) I shall add it to the first post.
Banned User
B
50
S
24
G
14
Posts: 637
Reputation: 12,503

Post » Mon Jan 15, 2018 6:00 pm

The reason I feel like I'm being trolled is because it seems obvious to me that the cause is in Windows, and there seems to be some insistence that actually it's our fault. So I'm going to drop my usual engineering equivocation and just say: this is categorically an issue in Windows. Does anyone disagree?
Scirra Founder
B
408
S
242
G
92
Posts: 24,929
Reputation: 198,711

Post » Mon Jan 15, 2018 7:00 pm

Im just happy it still works with that much crap added.
Image ImageImage
B
173
S
50
G
195
Posts: 8,575
Reputation: 121,886

Post » Mon Jan 15, 2018 7:31 pm

Hi folks,

Ashley, myself, and a few others had a very productive conversation on Discord. A lot of misunderstanding from all parties was cleared up and everyone who has been antsy like myself can rest assured knowing that Ashley has given with confidence he has spent a long time on this issue and has agreed we are far from a solution. It is entirely possible, this issue could go as-is for a long time. Sometimes, that is the nature of the beast especially with this type of issue.

We have agreed to put this to the side for a few days to allow for the air to clear a bit. And, if anyone has encountered tough issues before, sometimes simply setting an issue to the side and coming back to it later allows you to think more clearly about it.

If anyone finds any more data, or settings that mitigate the issue feel free to post them. But, for now, let's let the air clear before coming back to it.
Banned User
B
50
S
24
G
14
Posts: 637
Reputation: 12,503

Post » Tue Jan 16, 2018 2:51 am

I'm glad you guys had a talk and reached some sort of agreement.
Meanwhile I just want to demonstrate how bad Sprite Editor performance is on my Windows 10 machine.
It takes about 0.5s to draw toolbars, 2-4 seconds to open the little window with image points, and if I right-click on animation frame - 2-4 seconds to show the context menu. This happens even with very small sprites in small projects.

Youtube video

Rebooting Windows fixes this temporarily, restarting C2 doesn't.
B
17
S
9
G
128
Posts: 1,777
Reputation: 68,377

Post » Tue Jan 16, 2018 3:45 am

dop2000 wrote:I'm glad you guys had a talk and reached some sort of agreement.
Meanwhile I just want to demonstrate how bad Sprite Editor performance is on my Windows 10 machine.
It takes about 0.5s to draw toolbars, 2-4 seconds to open the little window with image points, and if I right-click on animation frame - 2-4 seconds to show the context menu. This happens even with very small sprites in small projects.

Youtube video

Rebooting Windows fixes this temporarily, restarting C2 doesn't.


@dop2000 the video you have clearly shows a worser case of the issues. It is frustrating indeed. I have hit similar timings at times on my machine (where the outline of the context menu shows, and it takes a few seconds to load contents). If your machine is powerful enough to run a Windows 7 VM, that could be an option for C2 dev for now. Not a great solution I know, but it is the best I have at the moment.
Banned User
B
50
S
24
G
14
Posts: 637
Reputation: 12,503

Post » Sun Jan 21, 2018 1:28 am

A bit of a long read. But, here is some concrete evidence, anecdotal notes, and trial runs about the issue which show roughly 20 hours per project can easily be lost to this bug (so, if you did 5 projects a year, that is roughly 100 hours of your time lost forever due to this issue . . . that is 2 and a half working weeks). It is important to note, these test below are only for the issue of the edit action functionality being slow. It is possible it is related to the other slowdowns experienced, but I could not validate that as it is too time intensive.

TL;DR;: C2 does not run well on W10. Even a small object count (such as sprites) causes slowdowns. The slowdown is overtime as you add more objects, so you don't notice and get "used" to it. By the time you notice, it is too late for your project. Layouts, layers, and global variables do not seem to contribute any notable difference to the general slowdown reported. Several W10 settings/optimizations were attempted with no real difference.


Ran some test with a fresh install of Windows 10, still, need to run a few more to be complete. Essentially going under the assumption *if* the issue is Windows, then there must be a way to make it better. These tests were using the same project each time, same edit each time, fresh reboot each time, and no other applications notably running (one drive shut down, nothing else really has been installed).

Quick Summary: No Windows changes made any real difference so far. However, selecting not to cache icons (within) made the biggest noticeable difference (but not enough of a difference).
Conclusion of the test(s) in this post: No significant change in performance, still at unacceptable levels. (See summary of time lost below)

Overview of time results
When I was done with this batch of testing:
First load (first action change) Icon Full Cache (C2 setting): ~3s
Subsequent loads: ~1.6-1.7s

First load Icon Cache Off (lowest C2 setting): ~1.7s
Subsequent loads: ~1.5s
Note: By load, I mean editing an action. The time it takes from clicking the action, until the dialog pops open.

Quick estimation of time lost in W10 versus W7:
Assume 5,000 events.
Each event has on average 10 actions.
Just to create these 50,000 actions is (best case): 75,000s lost (1,250 minutes or 20.83 hours)
If you do smaller projects, estimate accordingly (500 events means ~2 hours lost).
This is a rough estimation and in my opinion best case scenario. In reality, it is much worse because more than just adding/editing actions are affected as seen in @dop2000 video and others. This is also ignoring the slowdown overtime issue. It also ignores edits to actions (aka you wrote "perfect" code and ran into zero errors).


Test run so far:
Indexing completely shut off. No difference.
All background apps, telemetry, and so forth shut down. No difference.
Display settings set to best performance. No difference.
C2 in Compatability mode: No difference.
C2 with higher affinity/process power: No difference.
C2 with elevated priviledges: No difference.


Note: I did not test for extended use in these scenarios. This means, how C2 slows down while the computer is on longer. This type of test would be too intensive for all of the scenarios I am running.


Final thoughts
Once time allows, I have several other tests to run (such as caching size, paging, and some other test which I have run already but am now collecting concrete data on).

Side Note/Test
I wanted to see at what point did the project become fast again. I did a series of "reverse coding" or stripping down. Here is the results:
Deleted all global variables: No difference.
Deleted all sounds: No difference.
Deleted all but 1 layout and event sheets: No difference.
Deleted Sprites: This is where it got interesting. Deleting the first couple, took forever. You could see the Object Properties scan through every object (or so it seems). It took a couple seconds (5 seconds for the first batch) to delete each one (once less objects existed, it was near instant). It was not until I had a couple left did the editor become more responsive. By the time I deleted every object, the window pops after 0.2s (visibly, it is instant). A difference of ~1.5s. The dialog pops so fast, I cannot time it accurately.
This confirms what others have mentioned, about object count is the killer.
The project did not have that many objects to start with. Even at ~30 objects, the editor was terribly slow. (speed is directly correlated with number of objects/sprites as shown in this thread throughout numerous examples).
My question or thought as a result of this is , why would this slow down updating a variable in an action? What is C2 doing that is taking so long, if it is drawing icons as suggested in another post, something does not add up. Does C2 redraw the whole window, and all objects, when opening the edit action pane?

What I found from the above "tear down":
1) The editor for some reason goes through all objects below the object being deleted. I can visibly see the objects underneath being processed. If I have 10 objects, 1-10. If I deleted #1, I see 2-10 in the object info window. If I delete 9 I only see 10 get processed and it is incredibly faster than deleted #1. This means, if you had 100 objects, deleting object 1 will cause C2 to spin gears while you wait. This is not part of the bug (unless they are related, but I have no way of knowing), but an interesting finding.

2) More objects causes the project to go slower. Slow downs seem to be seen pretty easily. The slowdown is rapid and hard. When deleted the objects one by one, the editor got faster and faster.

3) Number of variables, does not seem to have any affect. Number of layouts either. Not in this test atleast.

4) Having Properties Bar, Project Bar, Layer Bar, Object bar enabled or disabled had no difference.

5) Having dozens of layouts + event sheets open versus just 1, made no difference.

6) Based on my tear down, if you hit this issue it is already too late. The object count is super low to start having issues, and its compounds in itself terribly. Re-use sprites as much as you can, but unfortunately, it seems even optimized projects with low object counts can hit this issue. I cannot think of a reasonable workaround at the moment, as any full-blown mobile app/game would reasonably go over this threshold of the object count. Since the issue is slowly rising, you get used to it and explains why so many people did not realize it was an issue until they compared between two projects, or compared W7 vs W10.

7) I tried moving objects into folders, this had no effect on action dialog time in the end. However, it did trigger the "slowdown overtime" issue. The dialogs took 4x as long to pop after moving a bunch of objects into folders. Upon a system restart, the times went back down. For example 1.5s load. Move a bunch of objects to folders. 5-6s load time for dialogs. Restart, back to 1.5s. This is unconfirmed if reproducible. If I have time I shall try this a few more times, it just takes forever to repeat since moving objects is crazy slow to do.

8) The issue is not resource bound. I tried this while mining on both CPU and GPU. Similar times were experienced (This was near constant 100% load on my CPU and GPU).
Last edited by humanescape on Mon Jan 22, 2018 2:07 pm, edited 3 times in total.
Banned User
B
50
S
24
G
14
Posts: 637
Reputation: 12,503

Post » Sun Jan 21, 2018 5:36 pm

So, real questions here: even if the issue is 100% "Windows fault," does that matter? The software is made to run on Windows. It's also still for sale. Shouldn't it be Scirra's responsibility to fix the software that is supposed to run properly on the platform it's marketed as being designed for? Does the placement of blame matter? Doesn't the responsibility ultimately fall on Scirra, the software developers, and not Microsoft?
B
100
S
55
G
27
Posts: 558
Reputation: 23,872

Post » Mon Jan 22, 2018 2:08 pm

If a Windows update slows down some Windows code that C2 calls, the root cause is categorically with Windows itself. We might be able to work around it, and I'm looking in to it today. What is annoying though is when users blame us specifically for the problem, when all the evidence points to it not being our fault. It sucks enough that we're a small team left scrambling to cover up for Microsoft's mistake, and then having people blame us specifically for the issue and refusing to accept the possibility that it could be anyone else's fault (as if we're totally incompetent and all problems are obviously our fault)... that's just salt in the wound.

Basically I think this would be reasonable: "Hey Scirra, it looks like a recent Windows update slows down C2. This kind of sucks, do you think there's anything you could do to help?"

But this is unreasonable: "A recent Windows update slows down C2. OMFG C2 is so crap and is broken. WTF is wrong with Scirra. Why haven't they fixed it already? Do they even know what they're doing? Unbelievably poor service OMG!" (Maybe nobody used those exact words, but it's definitely the impression I get)
Scirra Founder
B
408
S
242
G
92
Posts: 24,929
Reputation: 198,711

PreviousNext

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 3 guests