Poor performance overall

[LPGhatguy]

I'm running the Sublime Text 3 build 3083, latest stable, and I started getting extreme performance issues using this plugin.

When I have no tsconfig.json file, it looks like this plugin tries to parse all of my dependencies every time I type a semicolon, which stalls the entire text buffer. Adding a noParse entry to a tsconfig.json file fixes this issue, and changes nothing about the resulting file completion.

[hoanhtien]

@LPGhatguy Could you provide the following information to help us reproduce this issue:

• Could you send us a repro file/project?
• Do you have other plugins installed?
• Do you see any error printed in the Sublime console (before and after typing a semicolon)?
• Do you install the plugin via package control (latest version is v0.1.7) or download it from Github?
• Are you on a PC or a Mac? How fast is your machine?

[LPGhatguy]

It's on my work system and I'm at home, but here's some partial information:

• It's a 2012 iMac running the latest version of OS X
• The package was installed via Package Control
• No other plugins installed

I didn't check for errors in the console, but I can when I get in on Monday.

The bare minimum project I got the error occurring on had:

• a package.json with dependencies on jQuery, Handlebars, MomentJS, lodash, and coreJS
• a typings folder with .d.ts files for each of the above dependencies
• a main.ts that references each of the definition files, and imports each module

[LPGhatguy]

I checked this morning and there are no errors, but I do see

insert
queue timeout

every time I insert a semicolon with several libraries as dependencies.

The only place I see that throws a message like that is typescript/libs/node_client.py

[LPGhatguy]

I'm getting this same issue on my Windows 10 system at home, also with a bare minimum project. This project has the structure:

• src
  • client
    • main.ts
    • ModuleA.ts
  • server
    • main.ts
    • ModuleB.ts
• tsconfig.json

Where my tsconfig.json is just:

{
    "compilerOptions": {
        "module": "system"
    }
}

[LPGhatguy]

This problem has gotten to the point where it's causing my editor to hang indefinitely when adding imports to a file. The editor resumes operation when I kill my Node executable.

As a sidenote, this is using io.js 3.0, @hoanhtien.

Here's an error log from after I kill the node process: http://hastebin.com/ezekacuhah.txt

It appears that this is not related to the tsconfig.json file.

[zhengbli]

Is it possible you can put out the small project somewhere that we can test on it? io.js might be the problem as we've been testing on node only. And judging from the error log, it keeps trying to config the formatting options, which happened before when people are using the 'vintage' mode. Are you using it by any chance? Thanks

[LPGhatguy]

@zhengbli, I'm not using vintage mode on either of the machines I experienced slowdowns on.

The real-world project I hit the issue on most recently is here. It's not completely boiled down, but I hit the issues in both source files within src/server.

[billti]

We had some perf issues with the module resolution logic. We just implemented a change on the TypeScript side to improve this significantly (see microsoft/TypeScript#4154 ). This will be in the TypeScript 1.6 release (or you could build TypeScript from master and take the tsserver.js from their to dogfood it now).

[hoanhtien]

I see no performance issue when editing https://github.com/LPGhatguy/basis/blob/master/src/server/main.ts on a machine with io.js v3.1.0.

[LPGhatguy]

I haven't had any issues either since upgrading to io.js 3.1.0 -- perhaps it was one of the fabled memory leaks?

[LPGhatguy]

I've hit more performance issues again. It seems to correspond with type completion dying.

Could it be related to #348? There's a ton of I/O going on in the plugin it seems.

I followed @billti 's suggestion and I'm running the latest 1.7-dev as my tsserver now, which seems to have solved a bunch of other issues as well.

[zhengbli]

Can you show some of the I/O session that was recorded on your machine?
Some of the I/O are logged verbosely for debugging purpose, though it could also be something broken in the communication chain between the editor and the server. If you see a "timeout" message normally it is something bad happened.

[LPGhatguy]

Where would that I/O be logged by the plugin? The only indicator I had was a large number of temporary files in the plugin directory with open file handles (ie I couldn't delete them when Sublime was open).