3 ms·

at segment we benchmarked https://github.com/segmentio/ctlstore https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read perfor

at segment we benchmarked https://github.com/segmentio/ctlstore https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.

djbusby 4y ago
Really tho, how much is build time vs runtime? Maybe is just work small projects but I rarely care about build time. Am I missing something?
- collinvandyck76 4y ago
  If you have a lot of people and a lot of different builds it can become increasingly significant. It wasn't in our case, but it felt like it could have become so. And a lot of services wouldn't really notice too much if the occasional read from disk was slower, given that the nature of the data was control data.
- badtuple 4y ago
  Honestly, on a non-toy project, build times with cgo are _brutal_. I agree with you usually, but when a build time on a beefy computer switches from under a second to >1min you notice it. Linters and IDEs get slow when they check for errors, tests run slow, feedback drags, and all your workflows that took advantage of Go's fast compile times are now long enough that your flow and mental context disappear. I'm way more lenient with other languages since the tooling and ecosystem are built around long build times. Your workflows compensate. But Go's tooling and ecosystem assume it compiles fast and treat things more like a scripting language. When that expectation is violated it hurts and everything feels like it's broken.
  - bombolo 4y ago
    Why would you have to recompile sqlite every time? I guess you just need to compile the .a once and then just reuse it? If you're rebuilding it every single time, your build is set up wrong.
  - _ph_ 4y ago
    In my experience, encapsulating the access to sqlite in a go package helps a lot with avoiding recompilation of the c source, which indeed is brutally slow. It acutally seems to be way slower than compiling with gcc from the command line. Anyone knows why this is the case?
- deleted 3y ago
  [deleted]

djbusby 4y ago

Really tho, how much is build time vs runtime? Maybe is just work small projects but I rarely care about build time. Am I missing something?

collinvandyck76 4y ago
If you have a lot of people and a lot of different builds it can become increasingly significant. It wasn't in our case, but it felt like it could have become so. And a lot of services wouldn't really notice too much if the occasional read from disk was slower, given that the nature of the data was control data.
badtuple 4y ago
Honestly, on a non-toy project, build times with cgo are _brutal_. I agree with you usually, but when a build time on a beefy computer switches from under a second to >1min you notice it. Linters and IDEs get slow when they check for errors, tests run slow, feedback drags, and all your workflows that took advantage of Go's fast compile times are now long enough that your flow and mental context disappear. I'm way more lenient with other languages since the tooling and ecosystem are built around long build times. Your workflows compensate. But Go's tooling and ecosystem assume it compiles fast and treat things more like a scripting language. When that expectation is violated it hurts and everything feels like it's broken.
- bombolo 4y ago
  Why would you have to recompile sqlite every time? I guess you just need to compile the .a once and then just reuse it? If you're rebuilding it every single time, your build is set up wrong.
- _ph_ 4y ago
  In my experience, encapsulating the access to sqlite in a go package helps a lot with avoiding recompilation of the c source, which indeed is brutally slow. It acutally seems to be way slower than compiling with gcc from the command line. Anyone knows why this is the case?
deleted 3y ago
[deleted]