Fast Software, the Best Software
craigmod.com
craigmod.com
I agree on annoyance with "design changes" sometimes. Last weekend having the map always oriented to the North was driving me nut. They used to have a compass with a N to toggle it. While I was driving it took me 15 minutes to find the option under all the advanced options.
But that said I think Google is in general pretty good in trying to reduce the "featurite" in the app and simplify the UI.
200 Mbps
I do not have "Start AR" at the moment so I cannot test that.
-The app always loads with an "Explore {your_location}" card that takes half the screen. I am usually at my suburban house, near which there is nothing worth exploring. Even when I'm somewhere else, my primary use of the app is to get directions to an _already determined_ destination. The card is useless 95% of the time, but obscures half of the map, which is what I want to see and is so important as to be the name of the application.
-If I so much as brush the screen with more than one finger, it enters its 3D map mode. Like the "Explore" card, this seems to be screaming "look what we can do!", but it ignores what I want to do, which is navigate using the bird's-eye paradigm that has been used by every other map since the dawn of cartography.
-If I search for a place and tap a result, I get a full-screen card with information about that place, but no map. I just searched for "pizza" and tapped the first result and got a large picture of a pizza. I already knew what a pizza looks like, but I still don't know where the restaurant is. If I swipe the card down and then tap the map to try to get a better view of the restaurant's location, I lose the location indicator on the restaurant and the map re-centers on my current location.
I could go on, but I feel like an old man shouting into the void.
I chalk this up to Google Maps' overall bloat and sluggishness on my 2-year-old phone.
The music just cuts out for a few seconds, but there's no navigation audio.
I've turned off navigation prompts for that reason, and just check the "next turn" thing at the top every now and then.
No, straight from the phone.
Last weekend I had a friend in the car using apple maps on a newish iPhone, and every prompt from his phone was around a second earlier than from my phone. At 35 mph, one second is 50 feet (15 meters). That's enough to turn a safe maneuver into an unsafe one.
I use Google Maps many years already but it just became so slow in the last year or so. Maybe they just don't support non-high end phones anymore.
Now, I actually don't have a mapping app on my phone. It takes a little planning ahead, but I'm happier to do without.
Also, no lag (especially wierd lags) and no interruptions from notifications, phone calls and similar.
Google Mail is quite fast for me as well... And I'm not even using some crazy fast computer, just old PC with Core i5.
On a dual core cpu from 2014 with an ssd running linux I opened first firefox 70 and then chrome 75.
In both cases I was logged into my google account. In both cases I opened and then closed gmail to ensure what could be cached was cached.
In each I then entered mail.google.com and measured the time between hitting enter and seeing what looked like a usable interface. Lets compare that to other local ways of accessing email.
Running mu find maildir:/Gmail/INBOX took 9 ms this is easy to measure as it happens in the terminal.
Creating an emacsclient frame takes about 150ms added to the mu query which takes about 9. Logically there is some time required to render the view but its quite small and challenging to measure so lets say aprox 200ms or 1/5th of a second.
Loading the old school plain interface html interface to gmail took aprox 1.5 seconds.
It took 10 seconds in either browser to load the "modern" javascript gmail view.
For reference this is about 7 times slower than the html view or 50 times slower than mu4e.
Reading
https://www.pubnub.com/blog/how-fast-is-realtime-human-perce...
> A response time of 100ms is perceived as instantaneous. Response times of 1 second or less are fast enough for users to feel they are interacting freely with the information. Response times greater than 10 seconds completely lose the user’s attention.
This is why the slow loading Gmail interface has a loading screen so it is perceptibly doing something rather than appearing to be frozen. After this the interface is fast enough in the context of web apps wherein the user expects a small delay between actions but not as quick as a desktop app which can trivially be perceptibly instant.
Interestingly the old interface despite using vastly less ram and loading much much quicker initially appears to say load a message slightly slower than the slower loading interface so the optimum web interface would appear to be the slower loading more sophisticated interface if you don't mind keeping that browser tab pinned and always running.
A desktop app is still on the overall the superior option.
Is your gmail experience objectively different?
I don't know how could you expect ms-time response. I have 70ms ping to mail.google.com. It's just not possible for a web app to 9ms time response, unless you're living at data center. But as a web app, Gmail is amazing and pretty fast. I don't know why it's slow for other people, I'm not Google engineer and I don't have performance insights. I just telling that it's far from slow for me. Definitely not 10 seconds.
It's slow for others because a huge range of machines exist and tons have slower cpu, storage, or especially network.
Worldwide the majority is probably using worse machines especially in poorer countries than ours.
If you want to see fast mail, go load the basic html version of Gmail. I have it bookmarked because it loads as fast as you think it should.
Regular google mail loads so painfully slow in comparison, they needed a splash screen.
with possibly 8 gigs of RAM?
Thats still WAY faster than most machines being used in the wild.
Sorry, your SV bubble is showing.
The telsa maps are based on google maps.
I heard there were two ways to speed up maps:
1) turn off traffic, which significantly slowed things down
2) switch from vector maps to satellite maps. Apparently the map tiles of the vector maps require costly rendering for display, but the satellite maps just required a blit.
#2 may also explain #1, I'll bet traffic requires rendering too.
Switch back to version 9.42.3, or possibly a couple releases later if you need the "Favorites" and "Want to go" features in addition to just "Starred". It's pretty snappy and a breath of fresh air.
The only fix was reverting to the stock version, and it was AMAZING. So smooth. I had completely forgotten how fast it was while they boiled this frog's water over the years with their updates.
If I need to wait even a second for a page or app to respond per click, I am a lot less likely to _invent_ in your app. I won't stretch the boundaries, I won't do things that take more than 4 or 5 clicks. The app will _fit_ me less.
I will call up and ask for a feature that is a 6-7 click combination, if I am paying.
And if you build that feature, now you will likely have a slower product overall.
And also a slower product development org. Because more features mean more product managers. And more product managers mean more coordination meetings. And more coordination meetings mean... well you get the picture.
Love this post!
We too often worry about ticking off a checklist of use cases, and not enough about providing a flexible toolkit that can handle unanticipated use cases.
> I sigh — actually sigh — whenever I have to open Photoshop
Yep, quad-core laptop with fast SSD and I dread opening it. I remember being an early adopter with an SSD and I just used to open PS to see how fast it opened. They took that feeling away.
I now have a bookmark for the non JS version.
And they are probably optimizing for First meaningful paint (FMP) over Time to interactive (TTI).
Strange for a company that is putting this out: https://developers.google.com/web/fundamentals/performance/u...
It's 2019, the app is built by one of the leading tech companies, I have a modern device with good connection (not the absolute best I could get, but still OK). Why does it take like 5 seconds to load GMail? I would expect it to be ~1s, considering it's built by freaking Google. I'd expect some mega-optimizations going into this thing and to be amazed that they managed to squeeze everything out of a simple mail app. I'd like to imagine myself thinking I'd never be able to build THAT thing, yet it's not the case.
And it's not just the loading part - interactions even after first load feel sluggish. If you try the HTML version, it feels more responsive even just navigating the inbox. It could be psychological, but even in that case it would suggest that they need to improve the first load to make me feel like the app is fast in general.
I (at least internally) swear any time I open Google Maps, either by accident or when I can't avoid using it. Same for Google office suite webapps, which I avoid as much as possible.
oh yeah just remember to mention this thing, let me open my mail quick, ... Gmail loading... and the whole room fills with malaise.
I treat it just like how I treat the massive phone screen sizes and lack of stick shift cars in the US auto market. Consumers just don’t care about the same things I do.
After I disabled some extensions the Lighthouse metrics improved but not dramatically.
Are you using a privacy extension that keep clearing the browser cache? Did you try in a private window? Is it still annoying on the second load?
I don't keep the tabs opened. I close gmail when done reading or responding email (I check my inbox every 2-3 hours.) I even close the browser very frequently during the day.
The mobile web version. Works really well, even on a desktop!
The site takes so f*$%ing long to load you should have no problem clicking the "Slow? Try the Basic HTML version" link, maybe with 2-3 tries to figure out where it is (it's a small link). Then you should see an option to set it as your default.
Bonus: you can actually leave it open in a tab without eating three figure MB of memory and sometimes slowing down your machine doing god-knows-what in the background. Only downside is no notifications for new mail, but 1) that assumes you consider that a downside, and 2) that's what actual, native email clients are for.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
My company uses Outlook/Exchange and it also has a webapp; the website is pretty feature-rich and has a UI very similar to native Outlook, but it is blazing fast. The folks at Google are doing something very wrong to make it this slow.
Chrome 75.0.3770.142 with not extension active.
I've never used to commercial tools that their actual customers (advertisers) use, I wonder if they are more polished in terms of speed.
And then waited for it to load.
Did you have a warm cache for either? I find that Fastmail’s cold load is generally a fair bit faster than Gmail’s cold load, and Fastmail’s warm load is consistently faster than Gmail’s warm load; but Fastmail’s cold load can be slower than Gmail’s warm load.
I’m looking forward to working on service worker code loading loading and offline support in Fastmail; I expect us to get warm loading to under one second on a typical desktop machine, regardless of location (because it will require no network calls).
Either way, once the code has loaded, Fastmail is consistently snappier than Gmail. And uses far less memory (in Firefox, 10–15MB instead of >150MB). Offline mode will improve snappiness even further even if you don’t opt into actual offline sync, by virtue of persisting its data record cache. But that’s not implemented yet.
I was interested in what front-end library you guys were using so I did a bit of searching and found a twitter post about OvertureJS. I know this is kind of random, but I'd love to understand how you guys came to the decision to build a framework from scratch instead of relying on Angular/React. What kind of technical limitations did they have that you guys wished to tackle with Overture?
When you care about performance, there’s still a lot to be said for controlling the full stack.
Projects I've worked on have focused on being as minimal and lightning fast as I can possibly make them. If I add a new feature/query, and it's not instant, I don't ship it until it is.
I don't know where or when this became norm, but often times the difference between hours and near instant, is a matter of a simple query optimization. Waiting more than a few seconds for something to run is infuriating to me.
* Why waste development time on something that is only executed once a month, or once a quarter, or even once a year? If you don't need to iterate on the reports, waiting a while for something that is almost never done is fine
* Often simply adding a new index can reduce a query from hours to seconds. But why bloat your DB with an index and potentially reduce insert performance for something that's almost never needed?
Builds that take 5 minutes are a lower cognitive burden than builds that take 35, or two hours. If this is a worthwhile goal for your team, why shouldn't other teams want the same things?
Sure, there is always outlier consequences, but more often then not, these messes are the result of non technical people diving into the world of databases through excel and access.
if it works but slowly, then it was almost certainly done correctly by my book. you've implied as such - otherwise, you'd be making it done correctly first and foremost.
"done fast" more often than not involves non-measured details from parties often hovering outside the orbit of the customer, and you can bet trying to hit both targets leads to delays in shipping v1, which appears to work.
i praise those who ship software that works correctly, understanding that requirements, deadlines, and project timelines are completely lost when the source code is read on its own.
Nothing is free. Developers with more skills tend to cost more. BigCo. probably has some, but they are probably tasked with something else that BigCo. finds of greater value.
let's take an example that's not too far-fetched: legal comes and says that every month, you need to generate an report of some sort to comply with some regulation that corporations over a certain size must comply with.
you sit down and run v1 of the software which works but takes 24 hours to run. is your first instinct to get infuriated, as you said, even though from a requirements/company perspective, this is completely "done right"?
"the issue" is that changing software involves risks, which may be acceptable to you, but may not be acceptable to e.g. legal. they couldn't care less if it took 29 days to run or 29 ms. what they require - again, this is the requirement - is a monthly report generated, correctly.
and yeah, 99 times out of 100 you change the SQL correctly and it runs in 1/1000 of the time the first time. then for whatever reason it messes up one month and legal asks "what the F was this guy doing mucking around with this software which worked 'right'"?
The example you give is sooo right. And understanding the many levels of compromise between code speed, quality, legal implications, customer needs, management needs, cost, deadline, maintainability, technological choices made elsewhere, etc. is part of the job.
(personally, I have some priorities : meet the deadline comes first (descoping included), management at customer side comes next, then end users and, in the end code speed.
I'm gonna repost a chart I made previously[0]:
Spectrum of performance:
LO |---*-------*--------*------------*-------| HI
^ ^ ^ ^
| | | |_root of all evil if premature
| | |_you should be here
| |_you can be here if you don't do stupid things
|_you are here
--
If you've figured out that this is the case, the optimization is no longer premature.
For one, there are usually better arguments around code comprehension.
Pretty much the only time I hear this statement is as a response to criticism. That should raise some questions about the motivations of the speaker. Quite often it comes off as a dodge, and why and what are they dodging? Additionally, the whole quote is often at odds with the point the speaker is trying to make. It's not small inefficiencies, it's factors of 5, or 10, or an extra 6 months before we run out of headroom on something.
Aka the first refuge of the intellectually lazy.
(and the one who answers you has spent thousands of hours optimizing assembly routines for 3D engines, optimizing SQL queries to get the max out of some server, optimizing network traffic to optimize parallel computations,...)
If you're making a query that lots of users will run regularly, that needs an index. Period. Lots of the time there'll already be one, but that doesn't excuse you for not confirming and adding it if it's not there.
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." ~Donald Knuth (1974)
Now, this won't work for any kind of industry. Right now i'm in the business/government stuff. There, prototyping is much more important than speed of code. When I was in the gaming industry, the lack of speed was most of the time a technical debt. But even then, having my code working was much more important to the overall team effort than my code being fast.
So instead of your chart, I prefer : 1/ Code is working, 2/ Code is correct 3/ check for other priorities 4/ optimize as needed.
As for what you're expected to do and company value, my experience is that not so many people understand the link between actual code and company value (esp. in the top management where I sit regularly). You'd be surprised to see how much a deadline is more important than a fully working/optimized program ('cos for example the deadline is a trigger for a enormous change in the organization you work for (although we know the lack of speed in the code will have negative impact on dozens of end users))
so, well, it depeends :-) but still, a word of caution sound right to me :-)
Oh, for crying out loud: will you please stop trotting out this tired nonsense.
This may have been a problem sometimes in the 80s and 90s. With any good modern RDBMS, say SQL Server 2017 (but you can pretty much pick any you like the look of[1]), and a half-competent developer and/or DBA, insert performance is almost never a problem when adding an index.
You generally need some extra storage space for the index, but so what?
I have seen, with surprising regularity over the years, tables with no indexes at all where adding a single clustered index (which is the table itself) can massively improve performance. In this scenario no additional storage is required.
[1] I pick SQL Server because I know Microsoft started seriously addressing insert performance, which had been a problem with SQL Server 6.5 and 7, in SQL Server 2000. Nowadays, if you're half-competent, there really is no issue worth talking about. If you're not it is, of course, still possible to do crazy things that don't perform well. All truly powerful programming languages, database systems, et al., will cheerfully hand you the rope you need to hang yourself.
In an ideal world with a sanely (not over the top or inadequately) normalised database I'd agree with you. But in my experience there have been times where adding an index for a rarely run query was absolutely the wrong decision.
Of course, if you over-index a table, there can be some impact but in the general case that I've seen over the years that's seldom the problem.
* How many processes aren't executed more often because they are inconvenient? How much less efficient does this make the org?
* How much is index fear driven by 20th century hardware cost?
Anecdata:
In a prior job, I worked at a nonprofit that partially shares a CRM codebase with another ~30 peers. I cut query runtime 10x with a few indexes. I cut query write-time similarly by writing a few denormalized SQL views. The cost on CRUD transactions was marginal.
These queries drove mailings, marketing efforts, financial reporting, PowerBI dashboards, etc. Our peer organizations that used the out-of-the-box query tool favored SSRS reports for the same functionality, which meant that reporting was less flexible and more expensive to maintain. I can't prove causality but I believe query ease-of-use made a big difference.
Every time you want 10x the users, you need to make compromises in design to reach that goal... 100 users is easy, 1000-10000 you can hardware your way out. More than that, your design better be decent.
IME if you've got less than 100GB of data (maybe more on SSD) then correctly using indexes, joins and transactions will solve 90+% of performance problems and most things will be quite snappy without much tuning.
If a process takes a day to run, it won't be run daily. Period. It'll be run weekly or monthly or quarterly. But there may be value in running it more frequently, even continuously. But the present time cost makes that undesirable, and it's not perceived as adding value. Workarounds and alternatives are found, maybe. Or business units act on half-baked, likely out-of-date, information.
The hard part is translating frustrated users into financial cost (e.g. lost revenue when users are leaving for competitors and such) which in turn can be translated into hourly wage which then can be used to calculate if optimisation is worth it. And then compare to the lost opportunity of making other optimisations or improvements.
Obviously this is near impossible so the best you can do is make an educated guess.
Obviously you are, in fact, a meat robot, and if you'd care you could do better than "make an educated guess".
We couldn’t understand why on earth the team who made this database hadn’t bothered to make any considerations for read queries, but I guess worrying about insert speeds are more important than basic usability.
As you say, it's often as simple as adding an index, which have negligible downsides in 2019. It's a matter of caring about your craft and taking 5 extra minutes to do something right.
Developers making up arbitrary requirements based on what they want has causes me many a headache.
Generally as long as the feature is acceptably fast making it faster is likely a waste of time in most circumstances, especially when it comes to things like reports. Also it may come at the detriment of other considerations e.g cost, accuracy, code quality etc.
I used to work on high performance JavaScript and typically the things done in the name of performance make the code a lot harder to read and modify, this pushes up development costs of a feature quite substantially. I haven't seen the stats myself but I doubt it brings in enough extra revenue to justify the cost.
I am obviously not saying you shouldn't care about it, but it has to be taken with consideration of the bigger picture.
Yes. In all cases "being fast" is an arbitrary requirement, and a project lead or product manager should when hearing this requirement, interject and ask for a definition of "fast".
There are a thousand things at any company that could be done faster than they are. I could throw in eager caching or reindex data into aggregated documents in order to optimize that once-monthly report that takes an hour to generate, or I could automate the other once-monthly report that a group of folks assembles manually for each client. Which one is more valuable to work on? I could rewrite the server in Rust to get a 10ms response time speed up or I could work on the feature that will allow our sales team to be finally able to say "Yes, we do that" to the folks who previously turned us down due to feature parity. I don't live in a world where time is free, or where I can work on all of these things at the same time and still be done in the time it takes to do just one of them.
And all that additional logic and caching that could be added to improve the performance of some reports will be an increase of surface area for bugs and data discrepancies, and bring upon the team one of those hardest problems in computer science[1].
Or does it do something stupid, like manipulating a fixed but large amounts of data in a linked list, looking up in a linked list instead of a hash table, and/or passing lots of stuff up and down 20 layers of dependency-injected abstractions?
In my (arguably relatively brief) career, I've seen multiple cases where the core limit on product performance was something stupid that could be trivially identified with a profiler and could yield overall 10x boost of performance. Despite complaints from users, nobody really bothered to fix it.
When programs take a long time to run, they take also take a long time to debug. Your edit-run-test cycle is longer.
In my experience, programs that are unnecessarily slow are often also unnecessarily buggy. The main reason is that developers don't want to touch them. They rot in the background while the underlying data changes.
I'm talking about reports that take hours to run and often don't have any tests. It's pretty easy to get 10x improvement on such programs.
This doesn't conflict with the notion that most programs (particularly business reports) don't need to be optimized at all. They just need to be written with some basic understanding of the problem and the underlying platform. Tests go a long way too.
This is 100% true in my experience.
But overtime they ship 40 features in that way... and now the app take 220% more time.
It just slowly happen overtime and that it is why they may not notice it.
Products need to have performance tests with time limits that you do not want to compromise overtime.
I assume people who aren't as driven in their careers wouldn't want to mess with something that gives them hour-long breaks "waiting" on queries. I know I wouldn't :)
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
The low (initial) cost of them already explains it too well.
* My experience in University: I had to code in Assembly language, C, C++ (to learn about memory allocation, pointers, garbage collection - f*ck valgrind - ), Smalltalk / Pharo (for real object-oriented), Python / MatLab (for math things), and Java (for algorithms).
edit: Add Smalltalk/Pharo
A university CS program should force the students to deal with many languages and - importantly - their concepts. A single implementation language for all courses is certainly too little. Show them what it means to dereference a pointer in C, how to write a loop and a function call in assembler, what smalltalk objects can do by passing messages instad of calling methods etc. But I think that having a main language in a CS program is a good idea becaue it allows the teachers to pose more interesting implementation excercises if the students don't have to spend time to learn yet another language while trying to solve a problem.
All anecdotal, but I've seen a bit too much people with CS degrees who were clever enough, had all the knowledge, could produce smart algorithms and everything you want. But the code would just work and that's that. Like: build process only works on their machine, git history like written by a child or non-existent, code impossible to integrate in other projects, trainwreck-like, violating anything you can think of and so on. Is that bad? Well, yeah, but it's also pretty normal and it's not always problematic: teach them some more in an actual team and the really good ones will be better than you in no time.
Also, writing code that barely works and barely gets its job done is a skill ;). Ideally, it means that the person knows how to get something done with minimal effort when that is all that is needed. I noticed that I started to lose that when the projects I worked on became larger and had to meet higher demands. I tend to do stuipd things like one off scripts "properly" when simple hacks would get me there faster.
If I use free software, I will probably prefer to interact with the X11 API or GTK. If I want to develop commercial software I probably want to learn Windows APIs, etc. Forcing everyone into a specific OS is not a good way to teach IMO.
You could throw hundreds or thousands of tracks into your playlist and could scroll incredibly quickly through them, even on relatively slow PCs of the day. In an age before Spotify where to have vast collections was appealing, all my friends could scan each others' playlists and immediately start playing a song.
The speed of the software really did help discover new music. Scroll, double-click, scroll, double-click, scroll, double-click.
On the other hand: mpg123 on Linux played the same files with less than 50% cpu load! ;)
I personally love the keyboard shortcuts for finding music, queuing it, pause, play, etc; Very intuitive.
The observation is that a series of closely timed delays are experienced as a single, longer delay - or interaction - by the user.
The upshot of this is that a site where all pages are cheap but there are more of them may be more pleasant for the user than a small number of kitchen sink pages (finding stuff with the scroll bar is also slower). However, very very few of my employers have been willing to sign onto this.
Everybody wants their stuff on page 1. Page 2 at the least. Only losers have their information on Page 4. And if your stuff in on page 20... think of the shame. Can you even face your family for the holidays anymore?
What's really fucked up about this is that people consider carousels to equate to being on the front page. There are websites where I could visit literally every single page on the site in less time than it takes for the goddamned carousel to finish doing its thing. The inmates truly are running the asylum right now. Which is why I've done the Homer Simpson in the Hedge maneuver into backend work.
Of course, given the affordances of carousels, it means that no one is actually in the spotlight.
It’s been relatively easy to get rid of when it’s more of an “accident” than a political tool (or the result of the CEO/PM saying “can you make it more dynamic”), but when it’s tied to internal politics, it’s much harder to get rid of.
An area where I think speed is neglected is when people are thinking about what to build. Something I see mentioned occasionally by people here, on reddit, and by friends: They'd like to work on a side project but don't have any ideas for something useful to build. Just take something thats otherwise already useful but slow and make it not slow! These days you can't swing a dead cat without hitting a web app that doesn't need to be a web app, or desktop app built as a web app. There's no shortage of options.
A decade or so ago I was looking into reporting tools. Crystal Reports was getting expensive and I was looking for an alt. Some of them were faster at generating a several hundred page report but CR did something the rest didn't do. Instead of making me wait for the entire report to generate (several minutes) it would allow me to view the pages as they were generated. This meant I could read the first few pages while the rest were still in process. This made CR feel many times faster than the others.
I once made an app with an export feature. It was pretty slow (I benchmarked it against other tools and my tool was an order of magnitude slower)
But it was extremely responsive. The status bar updated frequently and was accurate, and a cancel button responded immediately.
People in reviews wrote that my app has great performance! Nobody complained that an export would take a minute! I did not expect that.
But then I realized that perception of speed / responsiveness is more important than actual speed. My app reacted instantly to user input, and never lagged, even while processing an export. I even wasted a lot of CPU cycles updating the UI to show status. But the result was an app that felt fast, and people really liked it.
For some reason, coffee machines with a built-in reservoir for coffee beans annoy me a lot more than the ones with a filter. For one with a filter, I know I have to put some coffee in it and fill the reservoir. I can determine the strength of the brew by this as well. The ones with built-in reservoirs should be able to give you a cup of coffee, but it is incredibly annoying when you have to suddenly refill the reservoir.
While the total work you do is less, the machine is unpredictable. It feels like the machine now controls you, instead of the other way around.
What makes it worse is developers keep harping on CPU/RAM being cheap and software on newer hardware is plenty fast to not only justify but promote bad software.
I wonder where they are seeing this "quick execution". I for one am unable to see it as hard as I try to look.
With Windows 10 and my i7, I usually expect a loading screen or two before I can use what I just clicked on (esp. Microsoft Office).
I believe the peak of user experience was Windows 98 sp2 when USB actually worked.
I miss how you could hear the computer loading stuff when the HD made the arm moving sound. When it took time to open "My computer" you could hear the floppy drive looking for a floppy and the delay was fine becouse the reason was obvoius.
I also miss the snappiness of Win32 GUIs just starting up in a heartbeat. No animations to hide bloat. If it crasched there was a blue screen and pushing the power button actually shuts down the PC power instantly.
Oh, and spamming ctrl-alt-delete resets the computer.
I created two emulator instances, API levels 21 and 28 (Android 5 and 9 respectively), identical emulated hardware. The API 21 VM is much faster than the 28 VM. It’s perfectly usable on my Mac where the newer OS is unbearably sluggish.
Why is that? With every Android release, there’s a song and dance about the work being done to reduce yank (“Project Butter” etc), so why does it keep getting slower?
Google have lots of amazing engineers, the world’s best datacenters and a vast pile of cash, so if they can’t win the fight against bloat, what chance do the rest of us have?
In short, I feel it's more an org problem.
Then there are the unavoidable features. Accessibility and localization are in that category. Suddenly you need to do extra work every step of the way. Look up translations, format strings with locale dependent rules, build a model for screen readers to process, alternate UI themes and layouts for vision impaired people... death by 1000 paper cuts, but also too important to ignore.
A huge and very easy opportunity. Current software is not just unoptimized, it is antioptimized to the neck. Any idiot could do far better than current "state of the art" if he is raised with prioritizing the correct things and understanding useless layers and crap for what it is.
There was a related thing that I heard from a previous CTO that changed my outlook on how to write web apps: "Users shouldn’t be able to tell that they’re using a web application. A web application should feel native. That is, it should load instantly."
Most companies: "Here, have this shitty UI redesign that makes our product worse and 50x slower!"
This ^ time’s a million
I would love to see people put efficiency at the top of every requirement list. With languages like Rust you don't even have to sacrifice productivity or safety to get it.
Python puts programmer read/write efficiency at the top of the list.
I’m not sure what Python’s priorities are, besides majorly sucking.
I can write software in Scala or OCaml or Racket in less than half the time of Python, while also being 10x faster.
Python needs to die. It’s the most worthless language I’ve ever been forced to use.
flat_list = [item for sub_list in orig_list for item in sublist ]
Using itertools
flat_list = list(itertools.chain.from_iterable(orig_list))
Would it really be bad if I could just do lst.flatten ? Or flatten(lst)?
I kind of assumed that DRY was a universally accepted principle in software engineering.
But I guess the Pythonic way is about copy and pasted code, no abstractions, wasting people’s time, egregious language inconsistencies, no multi-threading, and terrible performance.
I’ve probably written more Python than any other language, and honestly, using it feels bad. It feels outdated and useless.
There's a function to flatten an arbitrary iterable into a flattened iterable and a function to turn any iterable into a list.
> I can write software in Scala or OCaml or Racket in less than half the time of Python, while also being 10x faster.
Many people, on many types of problems, find the reverse of the first relationship.
After a decade of writing and maintaining Python, I've never needed to flatten a list.
> can write software in Scala
I have seen projects in Scala and can't make sense of the types or data flow.
When I show non Python programmers a snippet of Python they have a good chance of getting the sense of it.
At a previous employer, we had a test that took about 45 minutes, which most people just accepted as a fact of life. Unfortunately, we had to use this test a lot. After I optimized it (in my own time, because the team lead didn't think it had priority), it took 5 freaking seconds. Probably still far from optimal, but way more manageable.
“We’re on track to be the slowest productivity app on iOS! Let’s prioritize those responsiveness fixes!”, etc.
I've got a tool that analyzes ...lots... of data, and takes about 2 hours to run. This delay completely does not matter at all, when it's working. But man it's brutal when I have to debug some problem.
Arbitrary personal favourite: the Xfe file manager
I can't even
But the process of queuing that operation up should be lightning fast and the context menu to cancel a running operation or check it's status should be equally so.
For example when it comes to web development, today most of the people still choose solutions that by default always do diffing of the whole (virtual) DOM to decide what to change in the DOM and server side build ton of object to render HTML and destroy them after the rendering for each request (ex: React). You can argue that the React ecosystem will save you time in writing code because you can find a lot of good reusable components. Yes, but as you code grow, moving to a different framework (ex: Svelte), when and if necessary, is going to be a pretty large job.
You need to pick the right metric. The main one I alway look at is the ROI. Usually I take "user satisfaction and delight" as the "Return" and the time I need to develop the feature in that way as "Investment". The second parameter is usually the risk involved.
If writing it "faster" take 10% more time and is safe may still be worth to go the "faster" way. But when writing something "faster" start taking 200% and more risk is added, you want to be very careful. Is it really worth spending so much time on it?
Fast enough is fast enough.
You do not have to make everything the fastest you can. If a page takes 10 secs to load, what is the advantage for the user if you make it 10x faster? It is a huge win.
What if it loads in 1sec and you make it load in 100ms? Still a win.
But now what if the page takes 100ms to load and you make it 10x faster? Not a lot of people will notice the difference.
And if you have a page that loads in 10ms and you can make 10x faster nobody will even notice it.
So if you like to optimize, go look for places where "10x faster" actually matter.
It is more complicated in practice but keeping these principles in mind will save you a lot of time to work on what really need to be done.
The point is not to make it 10x or 100x or 1000x faster, it's to make it so that it is never slower than a monitor frame (e.g. less than 7-8 ms nowadays)
> macOS dialogs for closing an unsaved file have shifted from “Don’t Save, Cancel, Save” to “Delete, Cancel, Save.”
Does that mean if I write some essay, save it, then make some changes and close the application, it will ask this? This would imply like it would delete the whole file from disk instead of just discarding the changes I made since saving. I really hope I am wrong here and there is a different dialog for this case, otherwise this is just very horrible.
Cancel always cancels the action, allowing you to continue working with it. Save saves, obviously. “Don’t Save” means “continue the user action, which was closing the window, which closes the unsaved file, deleting the contents in memory”. “Delete” does a better job of capturing the consequences of the action here.
Not for me. If I haven't explicitly saved my document, there is no copy to delete. "Don't save" (which I am more accustomed to after using Macs FOR THIRTY YEARS) is what I expect.
macOS is trying to do away with the concept of "unsaved changes" altogether.
I recently started working at a company where we use Linux workstations. I work on a machine where I don't have sudo rights. Yesterday I asked a co-worker if he could install a package for me. From the time of me asking and the time that the package was installed on all the workstations, there was about 10 seconds. Nice.
Sure, it has way less features than other products, but I wouldn't be surprised if Jira's inherent slowness is what turns off a lot of people.
I have been on the lookout for one for quite some time now. I'm looking for something a little more user-friendly than say FFmpeg, but all the very feature-light and also feature-rich alternatives seem incredibly clunky and slow, even on my fast machine.
Thus far I've tried Shotcut, Premiere and Sony Vegas. I would be very grateful for any suggestions!
There's something just so wonderful about elegant, fast interfaces.
Loved this phrase.
Or put another way:
“Scientists have calculated that the chances of something so patently absurd actually existing are millions to one. But magicians have calculated that million-to-one chances crop up nine times out of ten.” ― Terry Pratchett, Mort
You could build your software in assembly but if each action has to hit a rest endpoint, the network request will utterly dwarf anything else happening locally.
So as more and more software moves to browser as web-apps this slowness is unavoidable.
Consider how more quicker and responsive Thunderbird feels to using gmail, a web-app.
There is a lot of laziness going on: not such an easy relationship between slow web and frontend as you describe. Most apps can work fine with stale data for most uses; they just do not because then the developer has to think about it and that costs money/time and takes talent.
Slack originally designed the app for one workspace. As users grew the expectations for multiple workspaces, they retrofitted by spawning a new thread for each workspace. eThey consciously traded off tech debt for growth. Now they've grown, they have invested resources to pay off the debt. And everything is one thread again.
OK, let's turn this into less of a rant: if you can do things in a native desktop app, you're almost always better off than with a browser based solution.
If you need networking, then you need to put up with latency and throughput. Thay is just unavoidable. What is avoidable is the overhead of unsuitable protcols. HTTP is perfect for one-off stateless requests for documents from a remote server. That is the whole point. But people crammed haphazard session tracking into it (cookies) and wonky authentication, then decided that having open sessions on the server is not something you do and layered an extra layer of statelessness on top of that while all the conplex browser based applications out there are actually incredibly stateful on the client and server. A native client that uses a custom tailor-made stateful protocol to talk to a server that also keeps session state would be much faster and more efficient than the shaky Jenga tower of compoments that are cobbled together to form the current generation of browser based software.
The reason fewer and fewer people are doing this are more to do with funding. So if I were to build software today, I'd instantly go with web-apps so that I can monetize them as much as I want.
Web app software has zero issues with piracy and in built regular cash flow model which everyone wants.
Find a way to fund desktop apps and make them as easy to build like web apps and they'll be vogue again.
And still, it's not applicable everywhere. E.g. if you're targeting business customers, the ones that can afford to pay you are also the ones that would be in deep trouble with the regulators if they pirated your software.
But that's just part of the problem. Unfortunately, with business customers, another big reason against desktop applications is that they can trivially work around the increasingly arcane and arguably bullshit approval and security policies corporations tend to have around installing new software. Though that seems to be changing; I've recently heard of companies using deep packet inspection to apply similar policies to SaaS webapps.
I disagree. I would say that web apps are popular because they provide more value. If/when users/companies demand native apps, developers build that instead.
Web apps are easier for users to manage (no installation, no upgrading versions) and instantly cross-platform. Installation is not trivial for a non-technical person, nor an IT manager monitoring and upgrading thousands of PCs and tablets. The natural revenue models fit because the value is recurring -- the subscription means you constantly have installation, upgrades, and data taken care of as a service.
> Web apps are easier for users to manage (no installation, no upgrading versions) and instantly cross-platform.
That's true, with a caveat that automated, forced updates are not an universal good - both for companies and individuals they're a source of risk and frequent frustrations.
> Installation is not trivial for a non-technical person, nor an IT manager monitoring and upgrading thousands of PCs and tablets.
This was mostly solved a good decade ago. Hello screen [Next>] accept the TOS without reading [Next>] leave default settings [Next>] uncheck the sneaky toolbar some morally deficient people put in [Next>] wait for install to finish [Done]. Sysadmins had a way to batch-install software in a non-interactive way. And these days, even Windows has a package manager that allows scripted installations.
> The natural revenue models fit because the value is recurring -- the subscription means you constantly have installation, upgrades, and data taken care of as a service.
Disagree. Installation is a one-time service, updates are as often undesired as they're not, and "data taken care of as a service" is bundling in something that should stay separate, in a sneaky attempt to lock the user in and ensure a recurring revenue stream. The case is simple: businesses like recurring revenue; everything else is either facilitating or attempting to justify it.
Turning products into services is one of the most annoying and anticonsumer trends of the current age. I get that business customers like it because of accounting reasons, but it's becoming a problem for everyone else. Next thing you know, you'll have to sign a TOS to use your hairdryer as a service.
On the PS3, I bought way less stuff in their store than I might have otherwise, because it was so damn slow, crashed so much (out of memory, felt like, but might have been something else), lost state all the time, and so on. It definitely felt like they were using a web view of some kind, probably with scripting enabled and in use, not just HTML+CSS for layouts & formatting or something. I'm sure that made publishing and adding rich content features ("just have a JS dev do it!") convenient. It also cut the amount of stuff I bought on there by at least half. There's no way I was alone in that—it was so, so bad.
Even on the much faster PS4 their store's unpleasant, though—barely, for now, until they bloat it with more JS as we approach the PS5—usable.
[EDIT] point being it wasn't the network requests ruining everything in that case, it was memory and processor hogging webtech on a machine that couldn't handle it yet should never have felt slow, going by specs, unless someone'd screwed up bigtime (say, by putting webtech on it).
The context here is that of the desktop software and the vast majority of desktop software is still not networked at its core. It is slow exactly because programmers used extra blubber layers to simplify their life, not because of the network API latency.
"simplify" lmao
Or rather to create an artificial market and justify their pay. More deeply, it is a symptom of our economic system that forces to do such things for having a living.
I wrote a simple web server in C and I was impressed by how tight my code had to be to reach the limits of the OS.
Even the internet is fast. Just look at fighting games. The simple fact they are playable over the internet is quite a feat. Fighting games require reaction times at the limit of what humans are capable of, and some moves require a 1/60s accuracy.
The problem is that there are so many layers of abstraction. You have the OS, JS engine, layout engine, frameworks, etc... Networking is just one of the layers.
Once your memory usage climbs and your OS starts paging/swapping things to disk, seemingly trivial operations that page in new code will take forever.
Linux desktop toolkits and dev environment utterly sucks. You'll have to develop 3 different codebases for Win, Mac and Linux. Worse still, you'll have to reinvent app updates technology if you go with Qt or will be tied into a different updating technology and still have to deal with piracy problems.
Or you could go with web-apps:
-> Easy to develop code
-> Can't be pirated
-> In built model of regular payments
-> One codebase for all platforms
It's not even a close fight.