Experiment: The hidden costs of waiting on slow build times
-
GitHub blog[^]:
How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think.
Another one to leave where your purchasing manager will find it
Counterpoint: xkcd: Compiling[^]
-
GitHub blog[^]:
How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think.
Another one to leave where your purchasing manager will find it
Counterpoint: xkcd: Compiling[^]
Slow build times are excruciating 5% of the time, and a godsend. I managed to read a metric ton of books claiming (verifiable) long compile times. In a company I worked for I altered the build script to run for 10 times with a pause between compilations so I could take one hour off while technically I was compiling. Yes I have a statue of Wally in my living room, how did you know?
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
GitHub blog[^]:
How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think.
Another one to leave where your purchasing manager will find it
Counterpoint: xkcd: Compiling[^]
Not only for compiling... My work laptop has been so bloated with things running in the background by the IT department that it takes around 5 minutes just to get ready to work after loging in. You can still fire things, but some (or many) of them will wait to pop up or start executing. But hey... they know it better.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Not only for compiling... My work laptop has been so bloated with things running in the background by the IT department that it takes around 5 minutes just to get ready to work after loging in. You can still fire things, but some (or many) of them will wait to pop up or start executing. But hey... they know it better.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
We have the same IT team. 80% of company works remotely connecting to remote VMs. Default answer of IT team to any type of slowness is: "It's the connection on your side." Even though it is quite easy to prove the VM running the person's desktop is running on h/w which is overwhelmed. Ce la vie.
-
Slow build times are excruciating 5% of the time, and a godsend. I managed to read a metric ton of books claiming (verifiable) long compile times. In a company I worked for I altered the build script to run for 10 times with a pause between compilations so I could take one hour off while technically I was compiling. Yes I have a statue of Wally in my living room, how did you know?
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Have you tried claiming IP rights on "quiet quitting"? :D
Mircea
-
Have you tried claiming IP rights on "quiet quitting"? :D
Mircea
I mastered quiet quitting in my first company, who paid a unskilled labourer wage to software engineers they trained and employed for 7 years. I also learnt by a previous master, a former coworker of my mother, who worked for the government. Every day he spent several hours cleaning his workstation, to the point he disassembled his keyboard and cleaned every single key before reassembling it. Every. Single. Day. Guess what I did when manglement imposed to the workforce to keep desks absolutely clean? Let it never be said that I forgot my masters.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
We have the same IT team. 80% of company works remotely connecting to remote VMs. Default answer of IT team to any type of slowness is: "It's the connection on your side." Even though it is quite easy to prove the VM running the person's desktop is running on h/w which is overwhelmed. Ce la vie.
raddevus wrote:
Default answer of IT team to any type of slowness is: "It's the connection on your side."
In my case, my answer would be... "You are almost right. The VPN connection speed on our side sucks and is a damned bottelneck"
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Slow build times are excruciating 5% of the time, and a godsend. I managed to read a metric ton of books claiming (verifiable) long compile times. In a company I worked for I altered the build script to run for 10 times with a pause between compilations so I could take one hour off while technically I was compiling. Yes I have a statue of Wally in my living room, how did you know?
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
When I read "I altered the build script" I was hoping for some genius tip on improving the build time.
-
GitHub blog[^]:
How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think.
Another one to leave where your purchasing manager will find it
Counterpoint: xkcd: Compiling[^]
Reminds me of a conference paper many years ago by database guru Jim Gray: The five minute rule. Then entire paper was three or four pages (or was it just two? The photocopy is too deep in my piles to digg it out ...). I think he used division in his calculations, but certainly no more advanced math or theory :-) By simple calculations, he showed that with the current prices, if you reference a data item every at least every five minutes, it is cheaper to buy more RAM to hold the item than buying a disk controller and a disk for swapping it out. This was way above common beliefs in the database world - no one would intuitively think that a value referenced only every five minutes, twelve times an hour, would deserve permanent residence in RAM! But Gray's calculations were so simple and lucid that they were obviously correct, based on the current prices of the day for IBM mainframe components. He was not rebutted. You could of course replace the prices he quoted with today's prices. Every now and then we did that, for the following years, and the five minutes increased to ten, fifteen, ... The commonly believed myth that you had to swap data to disk because RAM is too expensive "never" held water! (We are obviously talking about large database installations where you can save money on not buying yet another disk. You can't easily adapt it to a single-disc PC.)
-
When I read "I altered the build script" I was hoping for some genius tip on improving the build time.