Visual Studio 2017 : "We've noticed that extension 'Oxygene Editor Extensions' is slowing typing performance"

Thanks Marc. Appreciate it.

I’m told at least we could reproduce the issue (so that’s good), but it’s not quite clear yet what’s causing it, more investigation will be needed.

bugs://81764 got closed with status fixed.

Great this has a fixed status. Any chance of a beta build with it in ?

I’m still very much in a migration to a new development VM, so if there are rough edges to the build, not a problem.

i can send you a new build later today. what’s your account name in remobjects.com, ptthompson, same as here?

Thanks Marc. pthompson (one t). Hopefully that’ll fix things. The day is just about done here, so I’ll look to pick it up in the morning and report back.

1 Like

Up, on Personal Downloads.

Thanks, I’m running the 2366 build now. Obviously only had a couple of minutes using it… It does feel better (quite a lot), but I’ve readily just seen the popup in both simple and complex projects

I’ve not had the long delays yet. I’ll give it more of a run, but would you expect to still be seeing things like the above ?

A couple screenshots of the extension performance management dialog

and

It doesn’t feel like it’s causing a noticeable slowdown at the moment. It no longer feels like I’m trying to pull a truck whilst running uphill…

Hello,
At the moment Oxygene editor extension seems to show that error every starting of VS, though there is no real slowness. We have got an bug report to investigate it, but it might take some time.
Thanks in advance.

Hello,
I had this “slow” message until the version .2353 was out.
But today, with version .2365, it’s back!
I had it twice (one for 7 seconds) when opening CC.

Hi Patrick,

Marc provided a private build (2366) that does appear to have cleared the issue,at least for me. I was seeing the issue as significant pauses whilst typing in the editor. However I’m still seeing the “slow” messages, but it doesn’t feel like it’s actually slowing down the typing experience - more like VS being a little sensitive. I’ve also seen a couple of longer slow downs, at least one of those on the back of “building”. This screen shot shows the GUI after such a build.

Prior to private build 2366, Elements was pretty much unusable for me, even on simple projects. Now it’s perfectly usable, but I’d still like to be rid of those banner messages (I’d rather not go with the “Never show this Again” option).

Hi P (Peter, Paul, …?)
I see this today when CC is opened or a blank line is inserted.
It seems that version .2365 has made a regression on this, because I’ve never see them last month!

For you problem, I see that you’re running in a VM. Has the VM enough memory and CPU cores?

In my case, it’s native Windows 10 and a very fast machine, so memory, disk and CPU are not issues.

Hi Patrick,

Before .2366, I was seeing the issue pretty much constantly on anything I tried to do, CC , blank lines, anything. It was unusable really.

The VM shouldn’t be an issue, it’s a Windows 10 image with 8GB RAM and 4 processors allocated. The physical machine behind has 32GB RAM, SSD’s and a Xeon E5-2620 v4 processor.

As it stands, those messages I’m seeing are a minor annoyance, but would be good to get rid of.

(Paul)

Hi,

Can we return to this thread… I’ve continued to see the unresponsiveness issues and have upgraded from 10.0.0.2391 to 10.0.0.2437 in the hope of the problem having received further attention. No joy though, still getting the issue :-

Which results in this sort of thing…

If there is a common denominator as to when this kicks in, I’d suggest it could be when code blocks are incomplete / badly formatted. The example below kills the editor stone dead to the point where it could take a minute for a few typed characters to appear on screen. The rest of the code is correctly formatted and would compile (about 5000 lines in that file). If I insert a begin / end pair to enclose the two inner case statements, then the editor returns to normal, no lag whatsoever.

image

This is quite painful, but not a showstopper. Any fix / suggestions would be appreciated though.

Would you hap[pen to have a concrete project test case that shows this? (the actual slowness, not just the warning message)

Unfortunately not Marc. I did quickly try producing something trivial based on the above, but it worked fine. If I get chance, I’ll try cutting down the production sample into something I can easily pass onto you.

1 Like

:(. thanx anyway. we’ll see what we can do on our end…

What I just had now, when editing the generic.xaml file of a WPF control definition assembly:

Just when typing or after/before a compile?