What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.
By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max.
edit: probably this video https://youtu.be/j_4iTovYJtc?t=282
I've never heard of someone describing how long something took like this without at least defining the frame rate.
(actually, some things on the M1 are fast enough that I'm now getting annoyed at networking taking what feels like ages)
Does the refresh rate of a computer monitor get referred to as frames? Usually, it's just the frequency like 120Hz type units. Sorry for the conversation break, but I've just never heard app start up times with a framerate reference. Was just an unusual enough thing that I let me brain wonder on it longer than necessary
$ yt-dlp -F https://www.youtube.com/watch?v=j_4iTovYJtc
[youtube] j_4iTovYJtc: Downloading webpage
[youtube] j_4iTovYJtc: Downloading android player API JSON
[youtube] j_4iTovYJtc: Downloading player df5197e2
[info] Available formats for j_4iTovYJtc:
ID EXT RESOLUTION FPS │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27 │ mhtml │ images storyboard
sb1 mhtml 80x45 │ mhtml │ images storyboard
sb0 mhtml 160x90 │ mhtml │ images storyboard
139 m4a audio only │ 46.85MiB 48k https │ audio only mp4a.40.5 48k 22050Hz low, m4a_dash
249 webm audio only │ 49.06MiB 51k https │ audio only opus 51k 48000Hz low, webm_dash
250 webm audio only │ 63.84MiB 66k https │ audio only opus 66k 48000Hz low, webm_dash
140 m4a audio only │ 124.33MiB 129k https │ audio only mp4a.40.2 129k 44100Hz medium, m4a_dash
251 webm audio only │ 125.02MiB 130k https │ audio only opus 130k 48000Hz medium, webm_dash
17 3gp 176x144 8 │ 56.70MiB 59k https │ mp4v.20.3 59k mp4a.40.2 0k 22050Hz 144p
160 mp4 256x144 30 │ 37.86MiB 39k https │ avc1.4d400c 39k video only 144p, mp4_dash
278 webm 256x144 30 │ 42.59MiB 44k https │ vp9 44k video only 144p, webm_dash
133 mp4 426x240 30 │ 84.31MiB 87k https │ avc1.4d4015 87k video only 240p, mp4_dash
242 webm 426x240 30 │ 70.03MiB 72k https │ vp9 72k video only 240p, webm_dash
134 mp4 640x360 30 │ 167.27MiB 174k https │ avc1.4d401e 174k video only 360p, mp4_dash
18 mp4 640x360 30 │ 352.24MiB 366k https │ avc1.42001E 366k mp4a.40.2 0k 44100Hz 360p
243 webm 640x360 30 │ 134.68MiB 140k https │ vp9 140k video only 360p, webm_dash
135 mp4 854x480 30 │ 294.98MiB 307k https │ avc1.4d401f 307k video only 480p, mp4_dash
244 webm 854x480 30 │ 233.37MiB 243k https │ vp9 243k video only 480p, webm_dash
136 mp4 1280x720 30 │ 653.31MiB 680k https │ avc1.4d401f 680k video only 720p, mp4_dash
22 mp4 1280x720 30 │ ~795.07MiB 808k https │ avc1.64001F 808k mp4a.40.2 0k 44100Hz 720p
247 webm 1280x720 30 │ 548.72MiB 571k https │ vp9 571k video only 720p, webm_dash
298 mp4 1280x720 60 │ 817.18MiB 850k https │ avc1.4d4020 850k video only 720p60, mp4_dash
302 webm 1280x720 60 │ 651.39MiB 678k https │ vp9 678k video only 720p60, webm_dash
Not only Visual Studio s up instantly in an older version of Windows running in a VM. Debugger values update instantly there as well, something that Visual Studio can no longer do.
Not really related to launch time but it’s hilarious how much faster Xcode is when working with Objective-C compared to Swift. I understand why, but it’s still jarring
I really liked Win 2000 because of this feeling of speed. Most programs would simply "open" when you clicked their icon. There wouldn't be a loading screen. I remember getting frustrated because I could not look at the pretty spalsh screen that Excel had added because it would flash and disappear in milliseconds. Amd this was on hardware of that time.
Upvoted for bigging up my favourite (relatively speaking) Windows version. Still have my original disks.
Visual C++ 7 was rewritten to use another SDK, likely based on .Net, and it was noticeably slower. The problem, as I see it, is people don't understand the cost of abstractions and intermediate layers, and add them gratuitously. This has been a trend ever since.
But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all?
And that's not even mentioning the RAM elephant in the room: chrome.
Younglings today don't understand what a mindbogglingly large amount of data a GB is.
But here's the thing: it's cheaper to waste thousands of CPU cores on bad performance than to have an engineer spend a day optimizing it.
No, it really isn't. It's only cheaper for the company making the software (and only if they don't use their software extensively, at that).
Assume it costs $800 for an engineer-day. Assume your software has 10,000 daily users and that the wasted time cost is 20 seconds (assume this is actual wasted time when an employee is actively waiting and not completing some other task). Assume the employees using the software earn on average 1/8 of what the engineer makes. It would take less than 4 days to make up for the employee's time. That $800 would save about $80,000 per year.
Obviously, this is a contrived example, but I think it's a conservative one. I'm overpaying the engineer (on average) and probably under-estimating time wasted and user cost.
I 100% agree on saving human time. Human time is expensive. CPU time is absolutely not.
Adding more servers doesn't generally make things faster (latency). It only raises capacity (bandwidth). It does, however, generally cost quite a bit on development. Just about the only thing worse than designing a complex system is designing a complex distributed system.
If you don't want to take the advise of running the numbers that's up to you.
E.g. if end user latency is 10ms (and it's not voip or VR or something) then that's fast enough. Doesn't matter if it's optimizable to 10 us.
If this is code running on your million CPU farm 24/7, then yeah. But always run the numbers first.
Like I said, the vast majority of code optimization opportunities are not worth taking. Some are, but only after running the numbers.
On the flip side optimizing for human time is almost always worth it, be it end users or other developers.
But run the numbers for your company. How much does a CPU core cost per hour of it's lifetime? Your developers cost maybe $100, but maybe $1000 in opportunity cost.
Depending on what you do a server may cost you as much as one day of developer opportunity time. And then you have the server for years. (Subject to electricity)
Latency and throughput may be better solved by adding machines.
Using actual numbers vetted by actual expenses in an actual company, if you can save 100 CPU cores by spending 3h a year keeping it optimized, then it is NOT worth it.
It is cheaper to burn CPU, even if you could spend one day a year making it max out one CPU core instead of 100.
It can be better for the business to cargo cult.
Not always. But you should remember that the point of the code is to solve a problem, at a low cost. Reducing complexity reduces engineer cost in the future and may also make things faster.
Put it this way: Would you hire someone at $300k doing nothing but optimizing your pipeline so that it takes one machine instead of one rack, or would you spend half that money (TCO over its lifetime) just buying a rack of machines?
If you wouldn't hire them to do it, then you shouldn't spend current engineers time doing it.
I've seen people making poor decisions at the outset, and having code philosophies that actively make new code 100x slower without any clear gain. Over-generalization, 100 classes and subclasses, everything is an overriden virtual method, dogmatic TDD (luckily, nobody followed that.)
The dogma was to make things more complicated and illegible, 'because SOLID'.
Casey Muratori said it best: there are 3 philosophies of optimisation. You're talking about the first: actual optimisation where you measure and decide what to tackle. It's rarely used, and with good reason.
The second philosophy however is very different: it's non-pessimisation. That is, avoid having the CPU do useless work all the time. That one should be applied in a fairly systematic basis, and it's not. To apply it in practice you need to have an idea of how much time your algorithm requires. Count how many bytes are processed, how many operations are made… this should give a nice upper bound on performance. If you're within an order of magnitude of this theoretical maximum, you're probably good. Otherwise you probably missed something.
The third philosophy is fake optimisation: heuristics misapplied out of context. This one should never be used, but is more frequent than we care to admit.
> avoid having the CPU do useless work all the time
It's not worth an engineer spending 1h a year even investigating this, if it's less than 20 CPU cores doing useless work.
The break even for putting someone full time on this is if you can expect them to save about fourty thousand CPU cores.
YMMV. Maybe you're a bank who has to have everything under physical control, and you are out of DC floor space, power budget, or physical machines.
There are other cases too. Maybe something is inherently serial, and the freshness of a pipeline's output has business value. (e.g. weather predictions for tomorrow are useless the day after tomorrow)
But if you're saying that this second way of optimizing is that things should be fast for its own sake, then you are not adding maximum value to the business, or the mission.
Performance is an instrumental goal of an effort. It's not the ultimate goal, and should not be confused for it.
Then there are interactive programs. With a human potentially waiting on it. Someone's whose time may be just as valuable as the engineer's time (morally that's 1/1, but even financially the difference is rarely more than a single order of magnitude). If you have as few as 100 users, shaving off seconds off their work is quickly worth a good chunk of your time.
Machine time is cheap, but don't forget that user's time is not.
Run the lifetime cost of a CPU, and compare it to what you pay your engineers. It's shocking how much RAM and CPU you can get for the price of an hour of engineer time.
And that's not even all! Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent.
And if it has a bug because it sacrificed some simplicity? That's human hours or days.
And that's not even all. There's the opportunity cost of that engineer. They cost $100 an hour. They could spend an hour optimizing $50 worth of computer resources, or they could implement 0.1% of a feature that unlocks a million dollar deal.
Then having them optimize is not just a $50 loss, it's a $900 opportunity cost.
But yeah, shipped software like shrinkwrapped or JS running on client browsers, that's just having someone else pay for it.
(which, for the company, has even less cost)
But on the server side: yes, in most cases it's cheaper to get another server than to make the software twice as fast.
Not always. But don't prematurely optimize. Run the numbers.
One thing where it really does matter is when it'll run on battery power. Performance equals battery time. You can't just buy another CPU for that.
yet piles and piles of abstractions are considered acceptable and even desirable while having significant negative effects on code readability.
Say you need to do some data processing from format A to B. There's already a maintained codebase for converting from A to C, C to D, and a service that converts individual elements from D to A. All steps require storing back onto disk.
For a one-time thing it'll be MUCH cheaper to do it the naive way reusing existing high level blocks, and going to lunch (or vacation), and let it run.
For a recurring thing, or a pipeline with latency requirements, maybe it's worth building a converter from A to B.
Or… it could be cheaper to just shard A and run it on 20 CPUs.
Let's say you have the expensive piles of abstraction, and creating huge waste. At my company one HOUR of engineer time costs about the same as 20 CPUs running for A YEAR.
This means that if you reduce CPU use by 20 cores, forever, then ROI takes a full year. Including debugging, productionizing, and maintenance you pretty much can't do anything in 1h.
Likely your A-to-B converter could take 1h of human time just in ongoing costs like release management.
And to your point about code readability: Sometimes the ugly solution (A-C-D-B) is the one with less code. If you needed the A->C, C->D, D->A components anyway, then writing an A->B converter is just more code, with its potential readability problems.
On the flip side of this: It's been a trend for a long time in web development to just add layers of frameworks and it's now "perfectly normal" for a website to take 10s to load. Like what the fuck, blogspot, how do you even get to the point where you realize you need a "loading" animation, and instead of fixing the problem you actually do add one.
Human lifetimes have been spent looking at just blogspot's cogs spinning.
Given the choice between program X and program X plus higher speed at higher cost, some will choose the latter.
But that's never the choice. All else is not equal.
Even after closing all tabs, since tabs (and extensions) are basically programs in this operating system.
I'm only half-joking.
[EDIT] For extra lulz let them use a language with a bunch of fancy modern language features so they get a taste of what those cost, when they realize they can't afford to use some of them.
And microcontrollers will never get abundant capacity because smaller and more efficient means less battery, no matter the tech level.
So it's not like "everyone should know the history of the PDP-11" which I would disagree with.
During my schooling we built traffic lights and stuff on tiny machines, and even in VHDL, even though desktop machines were hundreds of MHz. They both have a place still.
The result is usually one CPU core running at 40% with sporadic disk access while you stare at Loading progress bar.
About pre-computing things (that's very likely the answer), the question is what things? Excluding Visual Studio, those are very plain GUI programs, that have a huge amount of options, but not anything near enough. And on the Visual Studio case, all the indexes and intelligence helpers are certainly cached to disk, as it's impossible to recalculate them at load time (the information just isn't there).
One thing those 3 have in common is that they have complete language emulation environments that are exposed to the user but are not related to their main function. Yet, language emulation environments start-up much faster than that, so they can only explain a small part of that time.
I didn't include the slowest starting software that I know, Oracle SQL Developer, because it's clear that all the slowness is caused by phoning home, several times for some reason. But that's not the case for all of them.
EDIT: Or, maybe it's useful to put it another way. The slowest region on the world for me to ping is around Eastern Asia and Australia. Some times, I get around 1.5s round trip time for there. A minute has around 40 of those.
At least VS is just kinda slow, maybe it's the XML parser :D
Work like in the OP's article is probably the most difficult - it's work that is necessary, cannot be deferred, but is still slow. So it requires an expert to dig into it.