5 ms·

Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds t

Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it. Kudos to the Vite maintainers!

jillesvangurp 7mo ago
Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes. With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart. Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system. The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests. I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes. There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life. And with agentic coding tools having fast feedback loops is more critical than ever.
- Sammi 7mo ago
  > I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes. For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.
  - yurishimo 7mo ago
    Assuming you use sqlite in prod or are willing to take the L if some minor db difference breaks prod... This method is actually super popular in the PHP world, but people get themselves into trouble if they tidy up all the footguns that stock sqlite leaves behind for you (strict types being a big one). Also, when you get a certain size of database, certain operations can become hideously slow (and that can change depending on the engine as well) but if you're running a totally different database for your test suite, it's one more thing that is different. I do recognize that these are niche problems for healthy companies that can afford to solve them, so ymmv.
    - torginus 7mo ago
      We've had this exact same issue (clean db for every test) - the way we solved it was with ZFS snapshots - just snapshot a directory of our data (databases, static assets, etc) - and the OS will automatically create a copy-on-write replica that can be written to, and the modification can be just thrown away (or preserved). Once you've created a zfs snapshot, everything else is basically instant and costs very little perf.
- esafak 7mo ago
  Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.
- panstromek 7mo ago
  > Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system. Yea, cypress has this in their anti-patterns: https://docs.cypress.io/app/core-concepts/best-practices#Using-after-Or-afterEach-Hooks https://docs.cypress.io/app/core-concepts/best-practices#Usi... Dangling state is useful for debugging when the test fails, you don't want to clean that up. This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.
Zopieux 7mo ago
I wonder what will be the parallel hindsight about waste, but for matrix multiplications, in a few years.
- _heimdall 7mo ago
  By then I understand that matrix multiplication will have cured cancer and invented unlimited free energy, so no hindsight of waste needed.
  - echelon 7mo ago
    Cure cancer? It doesn't have to cure cancer for it to make billions. All it has to do is put price pressure on your salary. (And it is already doing that.)
- xxpor 7mo ago
  The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles. Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.
semiquaver 7mo ago
The waste of slow JS bundles is nothing compared to the cost of bloated interpreted runtimes or inefficient abstractions. Most production software is multiple orders of magnitude slower than it needs to be. Just look at all the electron apps that use multiple GB of ram doing nothing and are laggier than similar software written 40 years ago despite having access to an incredibly luxurious amount of resources from any sane historical perspective.
- shimman 7mo ago
  Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc. It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box. There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).
  - ahtihn 7mo ago
    So you have free software that requires 2 GB of RAM and the alternative is $2k per month and you're complaining that the free solution is inefficient? Really? Why do you expect to be able to replace a 2k/month solution with a $10/month VPS?
    - xyzzy_plugh 7mo ago
      Because the fundamental task many of these programs are doing is neither complicated nor resource intensive. In the age of cheap custom software solutions everyone should at least try to make something themselves that's fit for purpose. It doesn't take much to be a dangerous professional these days, and certainly more than ever before can a dangerous professional be truly dangerous.
gtsop 7mo ago
[dead]
KronisLV 7mo ago
> Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." I feel the same way about tools like ESLint and Prettier as well after discovering Oxc https://oxc.rs/ https://oxc.rs/
flohofwoe 7mo ago
No worries, projects will soon catch up by throwing more code at the build system.

jillesvangurp 7mo ago

Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes. With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart. Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system. The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests. I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes. There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life. And with agentic coding tools having fast feedback loops is more critical than ever.

Sammi 7mo ago
> I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes. For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.
- yurishimo 7mo ago
  Assuming you use sqlite in prod or are willing to take the L if some minor db difference breaks prod... This method is actually super popular in the PHP world, but people get themselves into trouble if they tidy up all the footguns that stock sqlite leaves behind for you (strict types being a big one). Also, when you get a certain size of database, certain operations can become hideously slow (and that can change depending on the engine as well) but if you're running a totally different database for your test suite, it's one more thing that is different. I do recognize that these are niche problems for healthy companies that can afford to solve them, so ymmv.
  - torginus 7mo ago
    We've had this exact same issue (clean db for every test) - the way we solved it was with ZFS snapshots - just snapshot a directory of our data (databases, static assets, etc) - and the OS will automatically create a copy-on-write replica that can be written to, and the modification can be just thrown away (or preserved). Once you've created a zfs snapshot, everything else is basically instant and costs very little perf.
esafak 7mo ago
Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.
panstromek 7mo ago
> Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system. Yea, cypress has this in their anti-patterns: https://docs.cypress.io/app/core-concepts/best-practices#Using-after-Or-afterEach-Hooks https://docs.cypress.io/app/core-concepts/best-practices#Usi... Dangling state is useful for debugging when the test fails, you don't want to clean that up. This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.

Zopieux 7mo ago

I wonder what will be the parallel hindsight about waste, but for matrix multiplications, in a few years.

_heimdall 7mo ago
By then I understand that matrix multiplication will have cured cancer and invented unlimited free energy, so no hindsight of waste needed.
- echelon 7mo ago
  Cure cancer? It doesn't have to cure cancer for it to make billions. All it has to do is put price pressure on your salary. (And it is already doing that.)
xxpor 7mo ago
The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles. Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.

semiquaver 7mo ago

The waste of slow JS bundles is nothing compared to the cost of bloated interpreted runtimes or inefficient abstractions. Most production software is multiple orders of magnitude slower than it needs to be. Just look at all the electron apps that use multiple GB of ram doing nothing and are laggier than similar software written 40 years ago despite having access to an incredibly luxurious amount of resources from any sane historical perspective.

shimman 7mo ago
Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc. It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box. There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).
- ahtihn 7mo ago
  So you have free software that requires 2 GB of RAM and the alternative is $2k per month and you're complaining that the free solution is inefficient? Really? Why do you expect to be able to replace a 2k/month solution with a $10/month VPS?
  - xyzzy_plugh 7mo ago
    Because the fundamental task many of these programs are doing is neither complicated nor resource intensive. In the age of cheap custom software solutions everyone should at least try to make something themselves that's fit for purpose. It doesn't take much to be a dangerous professional these days, and certainly more than ever before can a dangerous professional be truly dangerous.

gtsop 7mo ago

[dead]

KronisLV 7mo ago

> Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." I feel the same way about tools like ESLint and Prettier as well after discovering Oxc https://oxc.rs/ https://oxc.rs/

flohofwoe 7mo ago

No worries, projects will soon catch up by throwing more code at the build system.