TypeScript Visual Studio Plugin may have Arthritis

Topics: General
Jun 11, 2014 at 9:21 AM
Hi, guys,

This discussion is with reference to the component that provides autocomplete, syntax highlighting, and inline error highlighting (red squiggly) in Visual Studio.

This component has been rather sickly since (I believe) the 1.0RC. I am somewhat worried about this because there has been no official acknowledgement of this problem, in spite of some noise on the forum and a couple of one star reviews that specifically mention this issue.

The basic problem (with some extrapolation by me) seems to be the following:
  • Something fundamentally changed in 1.0RC that was probably dreamt up as an optimisation for how the plugin builds up its database of information.
  • This wonderful optimisation has pretty much destroyed all the joy of working with TypeScript in large projects.
  • This optimisation probably improves working with smaller projects, which is why there hasn't been more noise around this.
  • If one has a setup where there is a single declarations file that is referenced by 200-odd typescript code files, and an edit is made to the declarations file then the old man exhibits the following symptoms:
    ** The IDE hangs when a new file, with errors from the breaking change, is opened.
    ** The busy icon shows up and disappears some four or five times, during which time the IDE is uneditable.
  • In other situations, even when there was no breaking-change edit made we experience the following all too often:
    ** When a file is opened "refreshing" shows up for much longer than it used to (say 5 - 10 seconds)
    ** It takes an age for the red squiggly to appear soon after a file is opened, after a change has been made in a related file.
    ** It takes an age for the red squiggly to disappear after the error is corrected.
    ** Vertically scrolling up and down on the file is sticky.
    ** Renaming a file is slow.
Given the symptoms it's not too difficult to guess that the mechanism that is responsible for providing the intellisense and error highlighting is not able to deal with the size of the code-base that we have.

I would like to know:
  • Is this acknowledged as a problem?
  • Is it recommended that the set-up of a single declarations file referenced across the code-base is no longer a good idea?
  • The idea that "TypeScript supports tools for large-scale JavaScript applications" is sadly no longer the case? (Of course I'm joking)
Looking forward to some feedback.


System Information
  • Visual Studio 2013 Ultimate.
  • TS 1.0.1
  • Other extensions: Node Tools for VS, Ankhsvn (No resharper or web essentials)
Jun 11, 2014 at 12:50 PM
Nabog, if you disable AnkhSVN does it get any better? It appears in other discussions I've seen on the issue (and within our team that also recently upgraded to TS 1.0) that if you disable the source code provider the IDE then becomes at least usable. It still is a dog, and all to often it sits for an age 'Generating outputs...' but at least it doesn't seem to bog down the IDE in its entirety.

This definitely needs to get sorted out, the current architecture appears to be struggling to keep up with some of the larger code bases out there. I am having doubts whether the decision to host the compiler within JS was ever a good idea vs. having a native compiler. Obviously I get that having it hostable in node or in another IDE will drive adoption, but it appears that not everything is right in the TS world.
Jun 11, 2014 at 3:35 PM
@Tharaxis, I did see the reference to Ankhsvn in the review and it does seem to improve the performance slightly.

I'd like to point out the following (as you probably will agree):
  • We have been using Ankhsvn for ages, well before TypeScript without any problems.
  • It's just not feasible to work without the source control plugin.
  • Unfortunately, all too often this discussion seems to end with "it's the problem of some extension or the other".
I kind of see this as a 100% TypeScript issue.

Having ported a large amount of C# code over to TS, I rather agree with the view that "the current architecture appears to be struggling to keep up..."

It's just painful to have to put with this after the performance we were used to with C#. Too often it's turning into a nightmare having to refactor code (renaming types, adding methods to interfaces, changing method signatures etc.) because that inevitably leads to the IDE slowing to a crawl.
Jun 11, 2014 at 6:16 PM
Edited Jun 11, 2014 at 6:16 PM
I'm working on a med-size project, and as well, I noticed that after using VS (2012 and 2013 - both of which behave the same) for a long time (I usually just hibernate and start up again later [never shutting down, because, frankly, it;s just faster]) the system hangs for seconds on literally every key stroke. Closing VS and reopening always fixes it for another few hours. I wonder if this is related to a resource leak somewhere ... ?
Jun 11, 2014 at 7:50 PM
@jamesnw, I've noticed that as well. Keystroke stickiness is also a common symptom since 1.0RC in the contexts I mentioned above.
Jun 11, 2014 at 9:48 PM
re: the source control plugin issue, that was 100% a TypeScript issue that will be fixed. There are other issues sometimes reported which are things that an extension is doing which we can't protect against, but this is not one of those cases.

@nabog We have also been making some fixes in areas that sound similar to the scenario you're describing. If anyone has a project affected by this behavior that they can share we would be happy to investigate. So I would say that we are aware of some specific issues here which we are prioritizing fixing, along with a continued focus on the general goal of continuing to improve performance for large projects (batch compile and language service operations), but it's possible that the specific circumstances involved in your issue are not captured in one of our bugs. We do have a variety of large projects we use for performance testing on a daily basis but obviously there are many different patterns and circumstances to try to account for.

There is definitely no guidance of "don't reference the same file from x other files or else performance will degrade," that should just work and be fast.
Jun 12, 2014 at 9:56 AM
@danquirk, thanks for the response. I appreciate that the nature of the problem is not very simple.

There are two issues here (both probably related)
  • Freezing up of the IDE when a large breaking change is introduced.
  • General sluggishness of the IDE when small breaking changes are made.
The following steps may help reproduce the first case:
  • Create a TypeScript project called "Interfaces" and add a large number of interface definitions to the project. There should be both standard interfaces as well as interfaces that act to describe object literals used in method arguments.
  • Ensure the project is compiled into a single output file, say "Interfaces.d.ts".
  • Create perhaps another 5 projects (we have more) with a number of TypeScript classes that implement the interfaces.
  • Each of these projects should reference the output file "Interfaces.d.ts".
  • Introduce a large breaking change by say deleting two thirds of the interface declarations in "Interfaces.d.ts"
    (In our case this turn of events came about because of issue #2523)
This may reproduce the case of the IDE freezing up. (Perhaps it might be possible to write a program that can generate the interfaces and the classes that implement them, in which case it should be easy to see the effects as the number of types are scaled up).
Jun 17, 2014 at 2:56 PM
Hi, I can confirm that I have similar problems. If I open some files, make some changes to source code my VS2013 process usage goes to 100% and stays there for 20sec or more. This makes VS totally unresponsive and editor is so sticky that it is unusable.

If I set “Options/Current source control plug-in” to none (I use git provider) everything works much better. So the solution for me is to switch source control on and off or to use command line for git.

@danquirk: are there any plans when source control issue will be resolved. I can also send you privately my source code if it helps.

Best regards
Jun 25, 2014 at 4:48 PM
Please also see @jpscott's description of the problem in a recently opened work item.
Jun 26, 2014 at 11:14 AM
Thanks nabog! Let's shout as loud as we can so MS can hear us! I love TypeScript, but it was supposed to be "made for big projects"... My project isn't 1/4 of the way finished and VS performance is already putting me behind schedule...

Hopefully some of these fixes get through soon...

I'll continue experimenting with different VS settings and see if I discover anything too!

Jun 26, 2014 at 12:10 PM
@jpscott, if you are able to zip up your project and send it to @danquirk by private email then they would appreciate that. (I'm not able to do that with mine, unfortunately.)

This is definitely putting me behind schedule as well.