Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A one-line change decreased our build times by 99%

medium.com

Post reply on HN
Print view View original

191–200 of 256 posts

Re: A one-line change decreased our build times by 99%

#191

Post by tetris11 »

dada78641 wrote: post #186

This reminds me of my first programming job in 2005, working with Macromedia Flash. They had one other Flash programmer who only worked there every once in a while because he was actually studying in college, and he was working on some kind of project from hell that, among other problems, took about two minutes to build to SWF. Eventually they stopped asking him to come because he couldn't get anything done, and so I…

I take it that this is not something he added himself, but was likely a catch-all default of textfields at the time?

Re: A one-line change decreased our build times by 99%

#192

Post by hadrien01 »

mcv wrote: post #162
amelius wrote: post #137

Earlier quoted context omitted.

Yes, there seems to be no way to make it clear to Google that we want to never see certain websites in our search results. Yet, Google claims they need our information to "improve our experience".

If Google wants my information to improve my experience, I'd love to be able to vote search results up or down. Or entire sites, like pinterest and content farms.

Wasn't that a thing? I remember a +1 button somewhere on Google Search

Edit: I misremembered, it was a social network thing from Google+ https://www.techspot.com/news/43064-google-adds-1-button-to-...

Re: A one-line change decreased our build times by 99%

#193

Post by sumedh »

detaro wrote: post #112
marta_morena_28 wrote: post #76

Earlier quoted context omitted.

It really doesn't sound complicated to find, unless you just have a handsoff approach to building things and just don't care as long as "something" comes out on the other end. What makes me wonder however is this: 40 min made them look into this? I mean 40 min is crazy long. What builds this long? Chrome, Windows, Linux Kernel on a single core? This should have been raising red flags much earlier. The only explanatio…

Remember "build" time likely also includes test runs, packaging for deployment, ... 40 mins is easy to get to, and has nothing to do with "on a single core".

You can still see which stages are taking a long time.

Re: A one-line change decreased our build times by 99%

#194

Post by casperb »

SamuelAdams wrote: post #189

> In the case of Pinboard, that operation would be fetching more than 2,500 branches. Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?

Probably because they have 1600 employees and the 2500 branches are the active ones.

Re: A one-line change decreased our build times by 99%

#195

Post by lytedev »

lytedev wrote: post #46
CGamesPlay wrote: post #32

Earlier quoted context omitted.

They set out to reduce build times, not to reduce git checkout times. It turns out that 99% of the entire build was spent downloading code.

This isn't true either, as the article says that builds went from 40 minutes to 30 minutes. The time spent cloning was presumably about 10 minutes and came down very far, presumably by 99%.

I stand quite corrected. Sorry, all!

Re: A one-line change decreased our build times by 99%

#196

Post by tetris11 »

SamuelAdams wrote: post #189

> In the case of Pinboard, that operation would be fetching more than 2,500 branches. Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?

If you have several releases with different targets, and want to make future security updates accessible to all

Re: A one-line change decreased our build times by 99%

#197

Post by DoingIsLearning »

SamuelAdams wrote: post #189

> In the case of Pinboard, that operation would be fetching more than 2,500 branches. Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?

They could already be doing that.

That is if we assume they copy google's philosophy of a single monolith repository.

Pinterest has about 2000 employees, assuming 20% are active developers thats about 400 people, that gives you roughly 6 branches per developer which wouldn't be outrageous.

Re: A one-line change decreased our build times by 99%

#198

Post by omegote »

tetris11 wrote: post #191
dada78641 wrote: post #186

This reminds me of my first programming job in 2005, working with Macromedia Flash. They had one other Flash programmer who only worked there every once in a while because he was actually studying in college, and he was working on some kind of project from hell that, among other problems, took about two minutes to build to SWF. Eventually they stopped asking him to come because he couldn't get anything done, and so I…

I take it that this is not something he added himself, but was likely a catch-all default of textfields at the time?

Yep. In order to use non-standard fonts in Flash I recall you had to embed the fonts, even if the movie clip containing the textfield was not being used anywhere.

Re: A one-line change decreased our build times by 99%

#200

Post by dahfizz »

SamuelAdams wrote: post #189

> In the case of Pinboard, that operation would be fetching more than 2,500 branches. Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?

Where I work doesn't delete branches, because there is no reason to. Git branches have essentially zero overhead and deleting them is just extra complexity in the CI toolchain. Deleting branches also deletes context in some scenarios. When dealing with an old codebase its nice to be able to checkout the exact version of the code at some point without having to dig through the log to get hashes and then dealing with a detached head.

The example in the article is a bit of a special case. It is a huge, and old, monorepo. In the typical case, fetching everything and fetching master is equivalent because all commits in all branches make their way into master anyway. If you have a weird branching strategy where you maintain multiple, significantly diverged branches at once, but only care about one of those branches at build time, then this optimization would save you time.

Post reply on HN