Koodihommia

VS code feels slow. All of a sudden, saving took forever in a TS project. The first suspect was a recently added WallabyJS test runner extension. So I disabled all plugins but still, saving took several seconds. My head then turned towards TS. Arrogantly I blamed some dependency but I had not a clue which one. Github TS wiki has some tips and tricks on what to do, including instructions to run a profiler. Turns out, a new profiling tool was introduced not too long ago in TS 4.1.  The output looks like this. Compiling the slowest source file takes more than 7 seconds! There is one massively slow checkSourceFile call which, as the name says, compiles a single file. To my embarrassment, it was in my code 😱 The profiling output is rather hard to decipher. The UI shows which TS internal functions are called and references a separate JSON file containing the type names. In my case, the slow function(s) included some weird single character type names, so it was not much help. The ...

I learned from my brilliant colleagues a nice trick that left me once again wondering why on earth I discover these things only now. It's funny to run into something literally everyone else knows, and somehow, I miss. Say you have a file that you want to download on some trusted server. You may have a version of the file downloaded, but it may be somehow corrupted or partially downloaded. You could verify the file integrity by comparing the local and remote file hashes, and that is indeed a proper way to do it.  If you trust the remote, you can use plain old HTTPS to get the headers only with a HEAD request and get the content length. Just compare the result to local, and there you have it, a naive yet adequate method to check if you need to redownload a file. Note that this does not validate that the file contents are equal.