In our system, users make changes to JavaScript files using the syntax editor in a WinForms app. When they save their changes the script is saved into a certain directory, and another Win32 console app which is running in the background picks up the change, reloads the file, compiles it and then executes it as required based on some external triggers. I noticed that the memory used by the long-running app seems to grow regularly, and it looks like it is related to recompilation of scripts as they change.
I was able to reproduce the leak using one of the demo apps. Steps to reproduce:
Run the demo app name ‘CallMethod.TypeScript’. Change the language to JavaScript and wait about 30s for things to settle. The memory usage of the app starts off at 300Mb initially on my system.
Click Start and once the animation starts, click Stop. Wait 30s or so for memory usage to settle - it now hovers around 320Mb.
Change the currentAngle value in the code editor to any random number between 0 and 360.
Click Start again and immediately click stop once the animation starts. Wait 30s for memory usage to settle. It now sits at about 410Mb.
If you repeat steps 3 & 4 multiple times, the memory used by the application grows by anywhere from 30Mb to 130Mb…and it never seems to be released no matter how long you leave the application running.
Thank you for reporting this problem. We looked at it and indeed there were memory leaks when recompiling JavaScript/TypeScript. It has been now resolved and the fix will be included in the coming update (expected around New Year). Let me know if you’d like us to provide a hotfix, so you can verify it’s working on your end.
Will prepare a fix and will send it to you ASAP. We’ve also added option to HostItem: GenerateDescription, which causes d.ts generator to include JavaDocs in the output file, which then are used to provide descriptions for code completion.
It should address issues with cashing d.ts files, memory leak and also allow to generate JavaDocs (you would need to set GenerateDescriptions option for the assembly host item):
The caching of the file and memory leak are fixed.
The GenerateDescriptions option also works - but only for System.Object methods. So things like Equals(), GetHashCode(), GetType(), ToString() etc all have JavaDocs text now being generated in the .d.ts file, but none of the /// style comments in front of my methods are coming across. That part isn’t that important though so I don’t need another hotfix for that.
Thank you for confirming that the issue with memory leak has been resolved.
With the documentation, it seems to work fine on our tests, provided that you have .xml file generated next to the dll. On our tests we compiled dll with Documentation File option on, so xml-comment descriptions from source are translated to the xml document. Then this xml document is picked up during generation of d.ts file.