Poor C2 Editor Performance On Larger Projects

— - you repeatedly said "C2 is broken on Windows 10" earlier in the thread, and now you say "No one is trying to blame anyone here". This is obviously contradictory. I've also seen you repeatedly edit previous posts in this thread, sometimes deleting a lot of content. I mean, this whole thing started with you pressuring us to fix it over the holidays treating it like an emergency even though we currently have other more serious issues. Frankly what I take away from that is your objective is mainly to troll over this issue and make everyone as upset as possible. This is a totally needless attitude; after this issue is resolved, I will be updating our bug report guidelines accordingly, so that no Scirra engineer is obliged to investigate an issue that users are being needlessly combative about.

If you feel that strongly about it, I am always available for a quick phone call to clear the air and misunderstandings. That said, I am not going to comment here about what you wrote as it is not needed for the bug.

Anyways, I'm looking in to the issue and I should have an experimental build out soon to trial a fix.

Great, can't wait to try it.

Anyways, I'm looking in to the issue and I should have an experimental build out soon to trial a fix.

We accept our faults if we ever had/have one! Because you have made a fix and we are very thankful.

That's so cool Ashley . We're ready to try it whenever you want when it's ready.

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)

While this position is somewhat understandable, I think it's maybe a little revisionist to assume that even a majority of people pointing out the issue place blame 100% on Scirra. This is of course aside from the fact that it's not really anyone else's problem that Scirra is a "small team" (wasn't C3 going to subscription supposed to help alleviate this issue?) or that the changes Microsoft made were a "mistake." It's their OS. Scirra (and every user) is a guest. Software is designed to run on their OS, not the other way around (also an issue that still exists with C3 and Chrome/NW.js, before we get into that sales pitch).

As for quality of service - dismissing issues that exist because they're not Scirra's "fault" doesn't change the fact that when the issues were initially brought up, the response from Scirra was...well, pretty dismissive itself, in terms of the impact the software issue has on its users.

Anyways. None of the rest of the noise surrounding it - as in, the emotional reaction of Construct's users or Scirra's - really matters. You've said it's being looked into. Great! Thumbs up all around.

This is genuinely probably the most effort I've put in to one issue out of the last 1000 bug reports. Right here you have the founder of the company directly trying to help you in an 11 page thread. I'm trying to handle this in a routine fashion, which starts by identifying the root cause. Once we have that, we can consider our options. Sadly sometimes there aren't any immediately obvious options (e.g. if we get hosed by a graphics driver on a particular OS/card combo) and I will say so if I think that is the case. Don't misinterpret that as dismissiveness; this is a routine engineering investigation and that's how it goes sometimes. Honestly, if you think after all this that I just don't care, I am sure nothing I ever do can possibly satisfy you, so why should I keep trying?

Anyways, I'm starting to suspect this really comes down to the Meltdown mitigation patches. A lot of things line up: the timing, the fact it seems to be in Windows code, and the fact the bottleneck on opening these dialogs could well involve a lot of system calls - all it'd need is one or a few system calls in the internal code to add an icon, plus the fact Meltdown's patches have been known to cause major performance regressions to such code, plus the fact the regressions are worse on older CPUs (which explains why our mostly modern systems don't show much of a problem)... it kind of explains everything. Based on this theory I just released a beta of r251 which significantly reduces the number of system calls in this situation, thereby mitigating the performance overhead of the Windows patches for Meltdown. Please give it a spin - make sure you set the icon mode to "Don't show unique icons" to activate the workaround.

If this works, I think it will prove the theory, in which case I must apologise for blaming Microsoft - it would ultimately be Intel's fault Again, I'm not using blame to excuse myself from fixing it - I must point out we just did a beta release specifically to address this, so obviously we're working on it. It's that finding the root cause is essential to know what to do about it. Blame for the root cause, and obligation to fix it, are two separate issues that I think everyone is conflating. If Apple update iOS and totally hammer performance in apps, it's obviously their fault; in an ideal world, they will then fix it. If they don't, out of negligence, lack of caring, or otherwise, then they've screwed over the app developers who then ought to fix it. But in that case I think it's reasonable for the users whose app is now slower to at least have some sympathy for the app developer and co-operate with them. Accusing the app developer of having a broken app is both technically wrong and unnecessarily combative.

Anyways, the next step is: let me know how r251 works out.

So, did some quick test:

Add action (brand new): Unbelievably faster now. Near instant in one of my test CAPX's now.

Edit Action (existing): Much faster. On one of my test machine's (the same one I ran the fresh install test on in the previous page), the same one that reported about 1.5-1.8s is now taking ~0.5-1s. This is a huge improvement.

I did notice *some* actions are faster to edit than others. When editing a function action, it is noticeably faster than editing an action that was setting layers opac.

I then tried r251 on my more powerful machine. It is pretty much on par with my W7 machine. The W7 machine is an old laggy machine, but still out beats my 6700k beast. But, in comparison to speed previously witnessed this is a huge step forward. I would say the speed is within acceptable ranges now

Again, I have not done heavy testing yet. But these initial results are amazing.

Windows Update / Meltdown

It is worth noting, this issue was not caused by a windows update, or meltdown. For several reasons (not that it is too important, but to keep facts straight and prevent going down rabbit holes):

• The bug was shown on both AMD and Intel (there is meltdown and specter. one of them effects only Intel, the other is both AMD and Intel).
• This bug pre-dates meltdown updates, and was also tested on pre-meltdown updated machines
• a user actually reported better performance after the meltdown update
• it was shown early W10 had the issue (it has been there since the beginning of W10).
• Similar bugs were reported months and even over a year ago, showing this is not related to a recent update
• ...there are plenty of other test and benchmarks that could be run around Windows Update, but I don't believe they are too important given the vast amount of information already collected (and given the improvements with r251)

It is completely reasonable to assume (and probably did), updates may have caused the issue to get worse and better over time (one update makes it worse, the next better, and so forth). But, it would be incorrect to say without a doubt windows update or meltdown caused this bug when you look at all data at hand. It would be safer to say, this has existed since W10 was officially released (which has been confirmed through testing). Again, not too important, but it should be said to prevent people from going down the wrong rabbit hole.

Sidenote

A side note, there are still other issues in the performance that users have reported, such as slow image loader. I have done my best to keep those out of here and stay focused on the issue I reported which was slow dialogs mainly with adding/editing actions. My hope was they were related, but this fix did not fix the other issues. Unfortunately, the users affected by other slowdowns will need to create a new bug report. This one has worn me down, I rather not pursue the other issues at this point (and to be honest, the other issues do not affect me as much). I will, however, help anyone with testing that does try to pursue the other issues as it is the right thing to do (as so many have helped me with this issue).

Summary

All-in-all, initial results are great. One could say the difference is beyond great, it is fantastic.

Going Forward

I am quite happy with the performance right now. Others are still affected by similar issues but, if we look back at the original bug report, so far it is much better. I am going to plug away and see how it goes over the next week.

It took a lot of effort on both sides Ashley (there were plenty headaches on both sides). Ultimately, you came through and I am very happy with this release. I also recognize and appreciate the effort you have put into this at the end.

I would also thank everyone who helped test out this bug. This would have been impossible to fix without all of your help.

And with that...Program on folks!!

Edit: fixed broken list

Unfortunately, for me there is no improvement after installing r251.

I experienced the biggest lags in the Sprite Editor (see this video). Nothing has changed with the update. It still takes about 4-6 seconds from the moment I double-click the sprite till the moment that little window with Image Points opens.

Toolbars are updating slowly. If there are many animations in the sprite, clicking between them is painfully slow....

Startup time ~30 seconds before and after the update.

The lag when opening events dialogs:

small projects: no lag

big project (1500 events, 15Mb size): 1-2 seconds lag

System: Windows 10, Version 10.0.16299 Build 16299

i5-7200U CPU 2.50GHz, 8Gb RAM, SSD

I did a clean install of r251, but I didn't restart Windows. Usually after the restart C2 works really well for a couple of days, and then things start slowing down..

This thread is only addressed at the specific issue with opening event dialogs with very large projects. This issue appears to be worked around in r251, so closing. If you have any other issues, please file new issues following all the guidelines, otherwise we can't investigate them. Please keep separate issues in separate threads; it's confusing to pile multiple issues in to one report.

The fix in r251 is based solely on avoiding calls in to Windows. This proves that the issue is in Windows and not C2 itself. Despite the fact these kinds of issues can be extremely difficult to do anything about, we still managed to work around it anyway. Please note that in this case blaming C2 was jumping the gun! Next time it could be C2's fault, but we don't know for sure until the issue is resolved. So please take note that there is no reason to rant about how terrible C2 is before anyone knows what the problem actually is yet.

I am amending the bug report guidelines with the following. The list below is derived from this thread, which has examples of every one. In future if a similar thread is posted I would stop investigating it, based on these new rules.

[quote:l9ejscvt]

Don't troll the developers

Our staff are here to help you. We have experienced engineers who have dealt with thousands of bug reports. The vast majority of reporters are helpful and are happy to work with us. However if you don't co-operate or are unnecessarily combative in dealing with staff, we will close your report and stop investigating it. We will resume investigation on the report if someone files it complying with the guidelines.

The following list are behaviors we will see as trolling. If too many of these behaviors occur in one report it is liable to be closed.

• Insisting developers investigate the issue over holidays or weekends. Please be patient.
• Repeatedly nagging developers to investigate an issue ahead of schedule, or repeatedly bumping the thread.
• Exaggerating the impact of an issue, or otherwise acting as if your issue is so serious, it is the end of the world. This is rarely the case, especially if the issue is not new. Diverting attention can also end up postponing work on other genuinely more serious issues, harming other users. It is also unnecessarily aggravating.
• Constantly treating the developers with scepticism or distrust. We are not perfect, but we are experienced engineers. Please have a little faith. Sometimes we discuss the issue and make educated guesses. However there is no need to try to argue us down every time we say something; it is simply a waste of everyone's time.
• Throwing in unrelated bugs or gripes. Please don't muddy the waters by talking about unrelated issues, complaining about why your favourite feature is not implemented yet, etc. Fixing a bug is difficult enough as it is, and having a concise, focused approach gives us the best chance of fixing it.
• Blaming us before the issue has been fully identified. All software depends on a wide range of third parties, such as OS developers, compiler and library authors, driver developers, browser makers, and so on. We do routinely fix or work around issues which are not directly our fault, in order to try to make sure Construct works as well as possible. If we point to a third-party cause, it does not necessarily mean there is nothing that can be done about it, although it may make it significantly more difficult. Our normal routine investigation simply involves identifying the root cause before we proceed to mitigating it. There is no reason to launch in to a rant about how it's our fault. Often this is simply incorrect and may also cause embarrassment.
• Demanding a resolution when none is practical. Some issues will have no good resolution, such as an issue caused by a specific graphics driver version on a particular OS and hardware combination. It is not feasible to investigate such issues, particularly if the evidence suggests the problem is not in our code. It is also unreasonable to demand an explanation of the inner workings of these other pieces of software we've had no part in developing.
• Accusing us of not responding or not caring about the issue, particularly after we have already put effort in to responding or investigating it
• Arguing about whether or not what you did qualifies as trolling or not ("meta-trolling"). It is up to the judgement of our staff.