This project is read-only.

Long compilation time in 0.9?

Topics: General
May 7, 2013 at 4:28 PM

I'm using the LKG for 0.9 and I'm noticing that the compilation time is taking a long time.

I did a test creating a file with "class Test {}" and call "tsc test.ts" - the process starts and goes to 100% CPU for about 5 seconds in a i5 2.4GHz cpu.

I know its in alpha, but is this expected? 0.8 used to be almost instantaneous.
May 8, 2013 at 2:13 PM
I can confirm this behaviour.
May 8, 2013 at 3:25 PM
Yeap, this is a known issue. We just finished up with the rewrite of the language service and compiler to make them much faster when doing interactive editing. Since we're just wrapping up the switch now, we haven't had time yet to go back and optimize. We're looking into it.
May 10, 2013 at 3:46 PM
This is one of the biggest problems at the moment.

Since upgrading to 0.9, project compilation times in Visual Studio have increased dramatically.

I'm not sure what interactive editing means, but we're not seeing any improvements in the overall user experience.

The workflow I have in mind is: edit "foo.ts" then build the project via Shift + F6.
May 10, 2013 at 11:48 PM
Interactive editing basically means the Visual Studio experience, i.e., the speed with which accurate completion lists are displayed, the speed with which you can get Quick Info for an object, etc (or in theory other tools which build on our language service). These things should all be massively faster and more accurate than they were in 0.8.3.

If you're not seeing that be the case we'd be interested to see whatever project structure you have which is not improved.
May 12, 2013 at 2:13 PM

Interactive editing defined in that way is certainly much faster in 0.9. That was noticeable almost straight away.

I'm glad that has been fixed, because with 0.8.3 it was at times quicker to type out ILongAndUnwieldyName than having to wait for the completion list.
(There are a number of places where the completion lists don't show up at all. We will report these cases if they still exist after the stable 0.9 is out.)

My personal workflow is most often a quick edit and build. Rarely do I spent more than two minutes editing a file without building. One reason for this workflow is that many script errors are just not picked up by the Visual Studio real-time error underlining mechanism (the red squiggly line). Furthermore, with 0.9 there are many occurrences of spurious red squigglies popping up - often this seems to be a due to some stickiness, where the error does not go away after a related file has been corrected.

In the light of this mismatch between the code and real-time feedback, the best way to catch out errors is to actually build the project.

At present a project with 8 TypeScript files takes about 7-8 seconds to compile.
May 12, 2013 at 3:15 PM
Hopefully compile times will be dramatically improved in 0.9.0 stable release ...
May 13, 2013 at 11:30 PM

Hopefully you will see the speed and correctness of squiggles improve as we get closer to a final release and feel more confident in relying on them. There have certainly been a number of issues in the 0.9 transition with incorrect errors 'sticking' as you mention (particularly with generics and generic specializations). We've been making an effort to clean up all these cases as best we can, we certainly don't want you to feel the need to build to get reliable error reporting. In general I have felt the squiggles are fairly reliable with recent bits, if you have any cases that repro bad behavior do file issues.


Yes we are intending to invest in performance improvements for batch compilation as we get closer to final.
May 14, 2013 at 12:48 PM
@danquirk, glad to see you guys are on top of these issues.

The bugs with the Visual Studio real-time error reporting mechanism are rather difficult to reproduce, because most of the time they crop up when one is working on a file with a <reference> include that is importing types from multiple projects.

I've tried reporting a couple but they've generally been closed with a peremptory "Can't reproduce".

If the TypeScript compiler itself were organised into multiple projects then it is more likely that these problems that bedevil real-world projects will be more easily picked up internally.

Also thought I'd let you know that we think a great job has been done with the generics.
There is a critical bug that is preventing wider adoption in large projects: Because the compiled .d.ts files are faulty they cannot be referenced in other projects. We have had to remove the --declarations option and manually maintain the .d.ts files at present. I hope this will be fixed with the stable release.
May 14, 2013 at 10:22 PM
Yep, trust me I know how painful it is to try to get good repros for some of these editing related issues :)

It's useful to know you're seeing it particularly with /// references and multiple projects, I'll try to take a look at some cases like that. Glad you've been finding generics working well overall though.

As far as that declaration file bug goes, it should be fixed quite soon.
May 15, 2013 at 10:28 PM
@nabog FYI 974 is fixed as of this morning, in case you aren't subscribed to updates on the issue.
May 16, 2013 at 7:50 AM
Are there any instructions available how to use the lastest code from the develop branch for the VS Plugin and for the tsc command line compiler?
May 16, 2013 at 9:11 AM
@danquirk, thanks! (hopefully that will make it into the LKG before long.)

@TobiasHei, instructions are to be found here:

(The folder for typescriptServices.js doesn't seem to be right as specified in the post - just search for the file in Common7/IDE)
May 16, 2013 at 7:08 PM
How does one compile TS into an exe (tsc.exe)? The Jakefile only seems to have instructions for generating the tsc.js.

We'd like to try out 0.9.0 and use the new version (since the released alpha takes about 3 minutes to compile our code - compared to 20 seconds in 0.8.3), but we use the .exe as part of msbuild to do the compilation.
May 20, 2013 at 4:56 PM
Like you say, the Jakefile outputs the tsc.js, which you can run with any ES3-compatible JS engine. When we ship the .exe, we build it in-house and ship with a Microsoft JS engine. You could think of the .exe as the same as the tsc.js, except we pick the engine for you.