4 ms·
It sounds to me like they erred on the side of caution on this and initially only performed Git operations serially. Presumably this allowed them to iterate qui
by lojack 11y ago
It sounds to me like they erred on the side of caution on this and initially only performed Git operations serially. Presumably this allowed them to iterate quickly on a product without doing destructive things, with the downside being an unresponsive application. It likely wasn't built in to the product in the first place because it was seen as premature optimization. As the product matured it became more apparent that optimization was needed.
I'm also not so sure that this concurrency model was rediscovered. Sure, they applied it to Git, and created their own implementation, but they probably borrowed the idea from the countless Grumpy Old Guy's that have done this in the past.
Of course, this is all speculation. Feel free to correct me if I'm wrong.
- jconley 11y agoI've been a user of this client for quite some time, and I've always had to use it with a light touch. Click one thing, wait until done, click another thing. Basically serializing things myself, because even though the UI allowed the input, the state of things would get really screwed up if you did things concurrently. If concurrency control in a multi-threaded, multi-process, app is a premature optimization, well, wow. At the end of the article the author states: "Before these changes, GitHub Desktop suffered from race conditions as units of work would become interleaved in error. Since implementing the concurrent/exclusive locks we have seen an improvement in stability and performance. " Sounds like they used to just let the client spin up multiple concurrent operations fairly willy-nilly.