gulp-sourcemaps: Loading maps causes increasing time of task when running multiple times through watch
I have a rather large project with TypeScript which included a gulp.watch
task to monitor for change in the TypeScript source files and trigger the build task accordingly.
Recently (but I cannot point exactly) it started to need more time from compilation to compilation, starting with approx. 12s, then, 18s, 27s, 33s, 38s, and so on. Canceling the running gulp instance and restarting it on the command line restarts the compilation times.
When I turn off loading of sourcemaps (sourcemaps.init({loadMaps:false})
), this does not happen and compile times stay the same.
It tried to reproduce it with a small sample project but without luck. I profiled it with the Chrome debugger for NodeJS and can say that somewhere in debug.js/selectColor
the times increase because the parameter namespace
gets longer and longer on each iteration which affects the calculation of the hash.
For now I can work with the deactivated loading of sourcemaps. But can someone give any hint on what is happening? And I would also appreciate a more detailed explanation of what loading the sourcemaps does as I primarly did it because the Aurelia template did it.
Versions: Node 8.1.2 and 6.5 tested Gulp 3.91 and 4-alpha tested Gulp-Sourcemaps 2.6.0 Gulp-TypeScript 3.1.6 TypeScript 2.3.4 Windows 10
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 3
- Comments: 22 (3 by maintainers)
Rebuilt and it went away.
Hello @nmccready , your branch works for me. Consistent execution time during watch task with loadMaps = true. Thanks!
@ZoolWay I am pretty sure I have determined the leak is in debug-fabulous. I am still working on fixing it. I believe it is the spawn function.
I’ll work on releasing it; there might still be an issue as travis failed somewhere.
@nmccready version - compile time1/2/3 (seconds)
2.5
- 14/15/142.5.1
- 15/16/162.5.2
- 25/55/222.6
- 15/39/46/59@phated @ZoolWay Seems like
gulp-sourcemaps@2.6
issue reverted to2.5
- works fineSo this sounds like a possible leak in visionmedia debug . It also could be in its wrapper debug-fabulous as well. Guess I could start w/ some tests against debug-fab first and work down.