Live data from Hacker News

Tracking developer build times to decide if the M3 MacBook is worth upgrading

incident.io

291–300 of 432 posts

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#291

How much did the analysis cost vs the laptop upgrade?

Hahah good question: 2.5 days all in, including building the new hot-reloader which fixed a number of outstanding bugs.

- 1 day for hot-reload (I don’t think this should count tbh)

- 1 day for messing with data

- 0.5 day for write-up

Assuming my day rate is £1k/day (it is not) we land at £1.5k, less than a laptop and less than I’d pay for the impressions I got from my post sharing this on LinkedIn, so feels worthwhile!

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#292

I was curious about something the OP said. He said that they were going dockerless and that they do it in part to reclaim some memory on Mac laptops. Is anyone else doing this or why would anyone else do this?

Am OP: the Docker for Mac daemon can claim a lot of system resources and the FS can have a lot of latency.

This means devs have less system memory available for their host because it’s in the VM, battery is often harmed because the VM box is constantly churning, and as we run our Postgres database in docker the FS latency makes for a noticeably slower dev environment.

Docker is great for standardising the dev env but honestly, running Postgres locally isn’t hard, and we don’t have many other deps. If the quality of experience is better at the cost of the occasional “let me help you out with this pg_upgrade” then I’d consider that a win.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#294
post #200

Earlier quoted context omitted.

Fwiw I've spent my whole career doing data analysis but the ease at which I was able to use OpenAI to help me for this post (am author) blew me away. The fact that I can do this type of analysis is why I appreciate it so much. It's one of the reasons I'm convinced AI engineering find its way into the average software engineer's remit ( https://blog.lawrencejones.dev/2023/#ai ) because it makes this analysis far more…

I'm a data scientist and it's my first time seeing analysis of a dataset using prompts (as opposed to code : i.e. python/R/SQL). I'm slightly blown away! The plot titled 'Distribution of Builds by Platform and Outcome' looks professional and would take me 10-60 minutes using ggplot. The spacings between the text and other graphical elements are done well and would be time-consuming (not to mention bland) for humans.…

I think we’ll definitely see AI find its way to the notebook tools. Funny enough, you can ask the model to give you an iPython notebook of its workings if you want to move your analysis locally, so in a way it’s already there!

On the process: we’re using OpenAI’s assistants feature alongside the ‘code interpreter’. This means the LLM that you speak to is fine tuned to produce Python code that can do data analysis.

You upload your files to OpenAI and make them available in the assistant. Then you speak to the LLM and ask questions about your data, it generates Python code (using pandas/numpy/etc) and runs the code on OpenAI infra in a sandbox, pulling the results out and having them interpreted by the LLM.

So the plots you see are coming direct from Python code the LLM generated.

On how many times did I resubmit: quite a few. I’d ask for a graph and it would give me what I needed, but maybe the layout was bad so you’d say “repeat the above but show two histograms a row and colour each machine model differently”.

I was using a very recent model that’s in preview. It was a bit slow (30s to 2m to get a response sometimes) but that’s expected on a preview and this stuff will only get faster.

Hope that answers your questions!

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#295

This is a great write-up and I love all the different ways they collected and analyzed data. That said, it would have been much easier and more accurate to simply put each laptop side by side and run some timed compilations on the exact same scenarios: A full build, incremental build of a recent change set, incremental build impacting a module that must be rebuilt, and a couple more scenarios. Or write a script that…

I agree, it seems like they were trying to come up with the most expensive way to answer the question possible for some reason. And why was the finding in the end to upgrade M1 users to more expensive M3s when M2s were deemed sufficient?

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#296

Maybe before buying M3 MacBook for everyone you should consider splitting your 1M line code base to avoid recompiling the whole thing for every change.. I don't know well the go ecosystem at all but it seems to me you should really consider optimizing your code base for compilation speed before creating fancy build time chart per cpu with AI and buying hundreds of super powerfull and expensive machines to compile it…

We do frequently adjust the codebase to improve build times, but the developer productivity hit we’d take by splitting our app into several microservices would be much more substantial than much slower build times than we currently see.

We’re super happy with 30s as an average build time right now. Assume we spent about £50k for the entire teams laptops, how much time would an engineer need to break our monolith into microservices? How much extra investment would we need to make it work as well as our monolith, or debug production issues that are now much more complex?

I’d wager it’s much more than half an engineers time continually, at which point you’ve blown the money you saved on a solution that works far less well for dev productivity and debugging simplicity in production.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#297
post #265

This is a great write-up and I love all the different ways they collected and analyzed data. That said, it would have been much easier and more accurate to simply put each laptop side by side and run some timed compilations on the exact same scenarios: A full build, incremental build of a recent change set, incremental build impacting a module that must be rebuilt, and a couple more scenarios. Or write a script that…

I didn't see any analysis of network building as an alternative to M3s. For my project, ~40 million lines, past a certain minimum threshold, it doesn't matter how fast my machine is, it can't compete with the network build our infra-team makes. So sure, an M3 might make my build 30% faster than my M1 build, but the network build is 15x faster. Is it possible instead of giving the developers M3s they should have inves…

What do you mean by network build?

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#298

Honestly, I found the analysis a little difficult to read. Some of the histograms weren't normalized which made the comparison a bit difficult. One thing that really stood out to me was: > People with the M1 laptops are frequently waiting almost 2m for their builds to complete. And yet looking at the graph, 120s is off the scale on the right side, so that suggests almost literally no one is waiting 2m for a build, an…

I think the main point was justifying getting new M3s

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#299
post #214

Earlier quoted context omitted.

Kind of interesting to think that CI is significantly slower in practice and both systems need to be maintained. Is it just the overhead of pushing through git or are there other reasons as well?

You would need a very perfect and flexible CI system in place that wouldn't need to rebuild anything it doesn't need and only run the tests you want or only recently failed tests etc. Many CI systems would spin up a new box instead of using persistent so likely have to rebuild if no cache, etc. So basically I would say most of the overhead is in not having a persistent box with knowledge of last build or ability to c…

Often you also have the CI system designed in a way to verify a “from scratch” build that avoids any issues with “works on my machine” scenarios due to things still being cached that shouldn’t be there anymore.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#300

If dev machine speed is important, why would you develop on a laptop? I really like my laptop. Spend a lot of time typing into it. It's limited to a 30W or similar power budget on thermal and battery constraints. Some of that is spent on a network chip which grants access to machines with much higher power and thermal budgets. Current employer has really scary hardware behind a VPN to run code on. Previous one ran a…

> Current employer has really scary hardware behind a VPN to run code on. Previous one ran a machine room with lots of servers. Both expected engineer laptops to be mostly thin clients. That seems obviously the right answer to me.

It's quite expensive to set up, regardless of whether we're talking about on-prem or cloud hardware. Your employer is already going to buy you a laptop; why not try to eke out what's possible from the laptop first?

The typical progression, I would think, is (a) laptop only, (b) compilation times get longer -> invest in a couple build cache servers (e.g. Bazel) to support dozens/hundreds of developers, (c) expand the build cache server installation to provide developer environments as well

Post reply on HN