5 ms·

Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventual

Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave. This regression had occurred without anyone noticing, because we all just assumed it was normal for 'build and bundle our typescript' to take a long amount of time despite how simple our code was.

fennecfoxy 4y ago
Granted, we have all moved from receiving updates to languages/frameworks once every 1-3 years (C# etc) or C++ with 3-8 years and instead get them monthly (sometimes even daily). Devs from the past who wrote chunks of FORTRAN that sat on a "dusty 386 in the basement for 30 years" are still around, what do they think of the constantly evolving field/goalposts vs more traditional, slower release cadence of languages/frameworks/software in general (afaik; I wasn't around for it).
thex10 4y ago
> It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow I've love to read a blog post about this.
spookthesunset 4y ago
I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds. I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your project that directly affects everybody working on it. Perhaps it’s because of the challenge and that most developers absolutely hate fucking around with the build system. Example: the parent poster. Build systems are can be pretty archaic but have a ton of features that most people don’t exploit. Perhaps it’s because it is easy to timebox and has a readily apparent set of diminishing returns. You can generally make a single change, push it to production and if that is the only change you made you’ve still added value. Perhaps it is because almost all of the changes you make don’t alter how the end user (other devs) use the build system. Short of swapping the build system entirely most of the time everything you do changes nothing for the developer. Perhaps it is because it is a good distraction from whatever it is you should be working on. You can squeeze it into spaces where you don’t have much in the pipeline or need to think something through. Whatever it is, I love fucking around with build systems.
- tracker1 4y ago
  Had similar issues with linting/formatting... switched to rome.tools a couple months ago and really happy with the change. I'm really looking forward to that project's goals too.
  - phist_mcgee 4y ago
    Hasn't rome had some dramas in the past? I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready. Happy to be proven wrong.
    - tracker1 4y ago
      I'm not really sure, I haven't followed the development that closely... I know I tried it... and it was pretty close... when I was ready to switch, had done some testing, and had to adjust several of the defaults to be closer to the existing linter config. That said, the reformat/lint-fix was so fast, it wasn't that big a deal. Did it in two commits, one with just the linter config, another with the reformats in a separate commit. The whole project can be scanned and reformatted and lint-fixes applied in under a second... the eslint config with TS took several seconds... as a precommit hook it felt pretty painful in practice, now you don't even notice it. If they do as well for build options (once added), I'll be very happy indeed.
      - phist_mcgee 4y ago
        The build step is the hardest of all. Just look at vite, it's amazing progress, but getting it to work with legacy codebases is a nightmare. Not having proper require support is a real killer. My bet is in 5 years we'll have massive buy in to these one-stop tools, but until then, they don't fit the real world as well as i'd like.
        tracker1 4y ago
        Vite is definitely an improvement over what came before (Parcel can be nice too). And yeah, migrating an existing codebase can be difficult, especially when you have other integrations (storybook, etc) that need to line up as well. Just updating libraries in use can be really painful if too much time goes by.
h1fra 4y ago
It's a common pitfall yes, especially bc of big libraries like gcloud (https://news.ycombinator.com/item?id=32307019 https://news.ycombinator.com/item?id=32307019) Build CI should be configured with a very aggressive upper limit to catch those regression but it's often forgotten; even I don't do it often while I have been bit more than once.

fennecfoxy 4y ago

Granted, we have all moved from receiving updates to languages/frameworks once every 1-3 years (C# etc) or C++ with 3-8 years and instead get them monthly (sometimes even daily). Devs from the past who wrote chunks of FORTRAN that sat on a "dusty 386 in the basement for 30 years" are still around, what do they think of the constantly evolving field/goalposts vs more traditional, slower release cadence of languages/frameworks/software in general (afaik; I wasn't around for it).

thex10 4y ago

> It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow I've love to read a blog post about this.

spookthesunset 4y ago

I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds. I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your project that directly affects everybody working on it. Perhaps it’s because of the challenge and that most developers absolutely hate fucking around with the build system. Example: the parent poster. Build systems are can be pretty archaic but have a ton of features that most people don’t exploit. Perhaps it’s because it is easy to timebox and has a readily apparent set of diminishing returns. You can generally make a single change, push it to production and if that is the only change you made you’ve still added value. Perhaps it is because almost all of the changes you make don’t alter how the end user (other devs) use the build system. Short of swapping the build system entirely most of the time everything you do changes nothing for the developer. Perhaps it is because it is a good distraction from whatever it is you should be working on. You can squeeze it into spaces where you don’t have much in the pipeline or need to think something through. Whatever it is, I love fucking around with build systems.

tracker1 4y ago
Had similar issues with linting/formatting... switched to rome.tools a couple months ago and really happy with the change. I'm really looking forward to that project's goals too.
- phist_mcgee 4y ago
  Hasn't rome had some dramas in the past? I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready. Happy to be proven wrong.
  - tracker1 4y ago
    I'm not really sure, I haven't followed the development that closely... I know I tried it... and it was pretty close... when I was ready to switch, had done some testing, and had to adjust several of the defaults to be closer to the existing linter config. That said, the reformat/lint-fix was so fast, it wasn't that big a deal. Did it in two commits, one with just the linter config, another with the reformats in a separate commit. The whole project can be scanned and reformatted and lint-fixes applied in under a second... the eslint config with TS took several seconds... as a precommit hook it felt pretty painful in practice, now you don't even notice it. If they do as well for build options (once added), I'll be very happy indeed.
    - phist_mcgee 4y ago
      The build step is the hardest of all. Just look at vite, it's amazing progress, but getting it to work with legacy codebases is a nightmare. Not having proper require support is a real killer. My bet is in 5 years we'll have massive buy in to these one-stop tools, but until then, they don't fit the real world as well as i'd like.
      - tracker1 4y ago
        Vite is definitely an improvement over what came before (Parcel can be nice too). And yeah, migrating an existing codebase can be difficult, especially when you have other integrations (storybook, etc) that need to line up as well. Just updating libraries in use can be really painful if too much time goes by.

h1fra 4y ago

It's a common pitfall yes, especially bc of big libraries like gcloud (https://news.ycombinator.com/item?id=32307019 https://news.ycombinator.com/item?id=32307019) Build CI should be configured with a very aggressive upper limit to catch those regression but it's often forgotten; even I don't do it often while I have been bit more than once.