[HN Gopher] We reduced our iOS app launch time by 60%
___________________________________________________________________
We reduced our iOS app launch time by 60%
Author : wallflower
Score : 180 points
Date : 2023-02-07 14:29 UTC (8 hours ago)
(HTM) web link (doordash.engineering)
(TXT) w3m dump (doordash.engineering)
| taytus wrote:
| I apologize if this comes out as negative, but it truly is an
| honest question.
|
| They are a tens-of-billions company. Why is this news? Shouldn't
| this be just part of doing business?
| kacy wrote:
| Because it's a helpful contribution to the the engineering
| community?
| taytus wrote:
| Helpful how? They used a third party library and they didn't
| even mentioned it.
| saagarjha wrote:
| Their goal wasn't to shame the library, but to indicate how
| one might do the same in their app. (And show that they
| have good engineers :P)
| dmak wrote:
| Recruiting
| joseph_grobbles wrote:
| It's an engineering blog targeting other engineers. Some
| engineers discovered something that had a significant impact so
| they are communicating it to more engineers.
| weberer wrote:
| Many people here are iOS developers who would like to see how
| to improve launch times in their own app.
| friedman23 wrote:
| It's their engineering blog... This is what engineering blogs
| talk about and you are on hacker news where things like this
| are of interest.
| lunarboy wrote:
| It's just PR, and/or some internal stunt by the eng team for
| better performance reviews. Both of which are fine, if the
| article itself is actually useful. In this case, I feel like
| the only thing that could have been interesting is the dyld
| workaround, but they don't go into depth with that at all. The
| first two "solutions" feel like they were just doing it
| inefficiently in the first place, rather than some novel
| technique worth sharing
| saagarjha wrote:
| Most performance wins are someone doing something
| inefficiently in the first place. Shocker!
| dagmx wrote:
| That's quite nihilistic.
|
| Why are any of the other posts on HackerNews here? Many are
| less technical or less interesting, depending where your
| interests are.
|
| This post at least shows how certain things might be debugged
| and some performance tweaks that people might forget to make.
|
| The bar for interest is arbitrary. One can choose to not engage
| and move on if they don't think it's interesting.
| bfeynman wrote:
| Doordash is a zombie company propped up by VCs, their tech is
| trash. I remember reading their "ML Engineering blog" and it
| was the most elementary crap every, they just used google maps
| apis for delivery and we're trying to do point in polygon
| calculations. The fact they herald things that are kind of
| simple and obvious to speaks volumes.
| colpabar wrote:
| Now if only they could retain the search parameters when you hit
| the back button. Currently it takes you to the default list with
| no filters applied.
| [deleted]
| thdc wrote:
| Impressive improvement, but is mobile app startup time that
| important after a certain threshold? I'm not a mobile dev.
|
| If the flame graph extends over the entire startup time, then I'd
| estimate it to be around 600-700ms (wish they gave the numbers
| rather than the percentage) which already sounds very nice as a
| user. If it was like 5 seconds then it would be amazing.
|
| Furthermore, I'm assuming that this only affects when the app is
| initially started instead of when it is already running in the
| background or navigating between screens, which is why I feel the
| linked article on why latency matters in tfa doesn't really
| support it.
|
| I'm curious about what metrics mobile developers use to
| prioritize tasks.
| MetaWhirledPeas wrote:
| > I'm curious about what metrics mobile developers use to
| prioritize tasks.
|
| This is a very MBA take. Task priority should always be
| considered beforehand, but whenever there is some leeway
| (including "20% time") I contend that _performance_ tasks
| should be given some preference. There is almost no end to the
| ill effects of slow software.
| [deleted]
| saagarjha wrote:
| Depends on what you consider important. Do you want to reduce
| churn? Optimizing startup performance is one of the best ways
| you can do that.
| mattgreenrocks wrote:
| Given the performance of most mobile phones, hitting below
| 400ms to launch and be usable feels like a low bar to cross.
| m3kw9 wrote:
| Yeah 600ms to 300ms is noticeable, if you play online games
| 200ms lag gets killed by 50ms everytime
| soiler wrote:
| But that's exactly the poster's point. You don't get headshot
| in doordash. Slightly slower performance doesn't actually
| change anything about your use of the app, until it becomes
| slow enough to make you stop using it (thus, the threshold).
| catiopatio wrote:
| Optimizing startup performance is respecting your user's
| time.
|
| "It's not slow enough to make someone give up" isn't a
| performance metric that puts your users first.
| baseballdork wrote:
| This is such a weird thread. The question was essentially
| about optimization having diminishing returns at some
| point. Yes, we can spend 10,000 dev hours getting another
| 50ms off the start time because that's respecting the
| user's time... but if nobody is going to leave because of
| that extra time, why not do something else with that
| labor?
| thdc wrote:
| Yes, and specifically because I believe startup time to
| be a rare occurrence when using an app.
|
| According to a talk I found [here](https://developer.appl
| e.com/videos/play/wwdc2019/423/): there are three types
| of launches; cold, warm, and hot. Warm is what's
| typically profiled and occurs when the app has been run
| at least once but has been closed since, while hot
| launches are what occur when bringing an app to the
| foreground. I assume warm launches are what are being
| profiled.
|
| I don't have any statistics, but my observation is that
| most people do not exit out of apps and instead just
| background them, which suggests warm launches are
| relatively rare if my understanding of which state
| triggers which type of launch is correct.
| saagarjha wrote:
| There are also prewarm launches, where iOS goes through
| part of the launch path on your behalf when it thinks you
| are likely to use the app.
| spacemadness wrote:
| It's a weird thread and not comparable in any meaningful
| way. Latency to actions performed multiple times per
| second to a one shot event is not useful due to it being
| an entirely different context.
| TillE wrote:
| Slow enough to notice is slow enough to annoy _somebody_
| out there. Yes certainly there are diminishing returns,
| but if you can be noticeably faster than your
| competitors, that makes a really good impression.
| soiler wrote:
| Ok, maybe I misrepresented what a good threshold is. I
| certainly don't expect developers anywhere to target
| "minimum viable load time". But the comment I was
| responding to was totally off the mark, so I was
| explaining that.
| saagarjha wrote:
| > I certainly don't expect developers anywhere to target
| "minimum viable load time".
|
| Is this not the job of your performance team?
| 0x457 wrote:
| Online multiplayer video game latency and app launch latency
| are very different things and perceived very differently,
| though.
| sond813 wrote:
| Apple recommends 400ms for startup time because that's how long
| the app open animation takes. It's also hard to tell from just
| one flamegraph how long it will really take in prod, that's why
| the percentages are nice to use. I've mostly used percentiles
| like p95 to track and prioritize mobile perf work. 600ms on one
| phone could be 2s on older hardware with other factors slowing
| it down, but it depends on the distribution of doordash users.
| thdc wrote:
| I actually came across the 400ms number in a 2019 WWDC talk
| while researching the topic! It said 100ms of that time was
| delegated to the iOS system for setup, leaving 300ms for
| whatever your app does.
|
| Granted the 100ms section included System Interface - DYLD3
| (dynamic linking) as part of it, which includes the 200ms
| portion that was optimized in tfa so I don't know how
| accurate that 100-300 breakup is.
|
| The talk also says to avoid dynamic library loading during
| launch to improve time which is interesting, as it suggests
| there's an alternative, which may or may not be what Doordash
| did here.
| saagarjha wrote:
| Using dlopen is generally not a performant option unless
| you are doing it off the startup path.
| kybernetyk wrote:
| For Doordash I'd say it doesn't matter if the app opens in
| 700ms or 7000ms. Hungry people are willing to wait a little to
| order their food.
|
| But then again: How did this get so bad in the first place? I
| mean, yeah, premature optimization and stuff ... but ...
|
| >One of the biggest immediate standouts was the time we spent
| on Swift protocol conformance checks (checking if a type
| conforms to a protocol), but why?
|
| Correct: But why? Why would you do this in a static typed
| language? Conformance checks should be a rare exception.
|
| >Architectural principles like the single responsibility
| principle, separation of concerns, and others, are key to how
| we write code at DoorDash.
|
| Oh, OK, architecture astronautics at play, I guess. Sorry, but
| you can separate concerns and all that other stuff without
| ending up with what looks like a dynamic typing system.
|
| /rant (I'm hungry)
| PragmaticPulp wrote:
| I generally lead teams to move quickly to get products usable,
| deliver the most important features to feed the business, then
| go back and start optimizing things like launch times.
|
| The DoorDash app is feature stable as far as I can tell as an
| infrequent user. It makes sense to have the team invest into
| small optimizations for experience and speed. Much better than
| letting idle hands start redesigning things that aren't broken
| or doing new features for the sake of doing more things.
|
| Also, a 600ms launch time on a high-end phone could be a 5s
| launch time for someone using a cheap, old phone. Optimizations
| are most noticed by the lower end of your userbase's hardware.
| m463 wrote:
| There are some tried-and-true principles that have worked since
| the dawn of computing.
|
| For example, if response time is less than 0.1 sec, whatever
| the user is doing is "interactive" and does not disrupt the
| flow of the task.
|
| I remember there were similar statistics for web page response
| time (number of lost views as response time increased). These
| seem like they might be similar to app launch speed.
|
| That said, I wonder if this "ios spp launch time" post was
| something that management pursued in a data-driven way, or some
| engineer getting annoyed and scratching an itch (or something
| in the middle)
| rocket_surgeron wrote:
| An astronomical simulator loading dark sky data, grabbing your
| location, charting the current positions of the stars in relation
| to your location, displaying detailed graphics for
| constellations, implementing gyroscopic controls for real-time
| manipulation of the viewport, and loading all overhead objects
| into memory: loads nearly instantaneously, responds quickly.
|
| A food delivery app: so bloated and sluggish it is borderline
| unusable and 100% embarrassing.
| baggy_trough wrote:
| If they care so much about the user experience, how come they
| never came out with an iPad version?
| hnthrowaway0315 wrote:
| Never done any serious development, can someone please educate me
| whether any of these three issues can and should be targeted
| earlier in development? For example is any of the first two
| directly going against some well known best practices? I'm judt
| curious, not trying to insinuating anything as I don't understand
| iOS development.
| bombcar wrote:
| Functionality first, but I'd say that you should have a healthy
| skepticism on third-party libraries - not a "we'll write our
| own instead" but a "do I really need this feature/tracking".
| marginalia_nu wrote:
| Actually, writing your own is often underrated.
|
| In many cases the time and code required to incorporate some
| aspect of a 3rd party lib to do something is similar to the
| amount of time and code in building what you need. In that
| case, the dependency only serves to make your code more
| complex (and slow).
|
| This is not always the case, but surprisingly often.
| marginalia_nu wrote:
| You'll want to fix most of the problems relatively late in
| development, although I can't recommend enough testing on the
| most low-powered hardware from the get-go. It will let you know
| immediately when you've written slow code.
|
| It's easier to fix a design mistake just when you've made it
| than when you've got six months of development hinging on the
| poor design choice.
| ab8 wrote:
| No. Functionality first. Optimization later.
| hnthrowaway0315 wrote:
| Gotcha, makes sense.
| saagarjha wrote:
| Profile when things become problems, generally.
| coldpie wrote:
| Using Strings in any performance-critical situation, like
| object identifiers, is a newbie mistake (but also extremely
| common). That one shouldn't have happened. The others just
| strike me as things one learns about and fixes as the project
| matures and someone bothers to do a perf analysis to find the
| low-hanging fruit.
| hnthrowaway0315 wrote:
| Thanks! Is the reason Strings impact performance because we
| can use smaller objects to do such work while Strings are
| larger?
| stefncb wrote:
| It's not necessarily about the size itself, but more about
| the fact that it has to go through a memory allocator and
| it has to be GC'd if that's applicable, while a simple
| integer doesn't. Copies are more involved too.
|
| Using strings for identifiers is almost always a bad idea.
| soiler wrote:
| Not something I had considered. So for example a UI
| component that might load 3 different versions based on a
| string identifier, should instead use an enum which maps
| to integers? I say an enum because this would preserve
| readability of the code.
| coldpie wrote:
| Do you mean an API entirely internal to your application?
| In that case, yes, you probably want to use integers
| (enums), not Strings, to choose what to display.
|
| If you are interfacing with other APIs that use Strings,
| it may make sense to just pass those through. For example
| loading files from disk or pulling up UI classes from the
| OS library using some String identifier or something.
| It's hard to say without more context.
| soiler wrote:
| Yes I was referring to internal APIs. Thanks
| saagarjha wrote:
| This is not true on iOS for most strings.
| stefncb wrote:
| Why is that?
| sixstringtheory wrote:
| My guess is they are talking about some optimizations iOS
| does to make strings more performant, like interned
| string constants and tagged pointers. The majority of
| string usage probably falls under those.
|
| Working with dynamically allocated strings, like reading
| from files, rendering from data bytes, working with C
| strings or building formatted strings, might have worse
| performance characteristics.
| stefncb wrote:
| I think that's something the language does. I struggle to
| understand how iOS would do it.
| saagarjha wrote:
| iOS interns heavily across programming languages, and
| tagging and other small-string representations are
| available for non-C languages.
| stefncb wrote:
| TIL!
| coldpie wrote:
| Basically yeah. At a super rough level of understanding,
| the CPU can compare two integers with one instruction, but
| has to loop through a whole string[1] one character at a
| time to compare two strings for equality.
|
| [1] Yeah yeah, CPUs & standard libraries are smarter than
| that, I know, I know. You get the point.
| saagarjha wrote:
| Most String comparisons are <5 instructions
| saagarjha wrote:
| ...this is not very good advice? Using strings is fine, until
| it becomes a problem. People are going to read your comment
| and decide to change all their strings to integers or
| something at the cost of maintainability.
| strulovich wrote:
| A lot is silly issues can be ignored in any small app, and will
| become big later on.
|
| If you picked good habits from past scars, stick to them.
| Otherwise, concentrate on functionality, dogfooding on real
| devices that real people have as much as possible, and use
| profiling to find the bottlenecks that emerge when you find the
| time (since you're focusing on functionality).
|
| (Exceptions to this rule exist, like if your product is some
| cloud service then speed might be an actual functional
| requirement of whatever you're building)
| hnthrowaway0315 wrote:
| Thanks!
| m3kw9 wrote:
| No this would be over optimization
| bcardarella wrote:
| It would be nice if DoorDash cared as much about their web app
| performance as they do their native app performance. Their web
| app perf is _abysmal_. Pathetically slow. Clicking takes
| _seconds_ to see a response in the UI.
| eddieroger wrote:
| I am not disagreeing that they shouldn't focus on their web
| app, too, but I assume they look at how often the mobile app is
| used versus web app and are just prioritizing for user base. If
| more people used web, I'm sure it would get more love.
| hansvm wrote:
| They really need to look at counterfactuals though - if our
| webapp were better how many people would use it. The fact
| that a mediocre site with a better alternative (the app and
| competitors) doesn't get much traffic should hardly play into
| the calculation at all.
| kredd wrote:
| Unlike HN users, supermajority of population is perfectly
| fine downloading and using an app. I would even say,
| opening a browser, going to a website, potentially logging
| in is more friction than "sliding down and typing doordash
| to open the app".
| hansvm wrote:
| That's fine. I don't have a horse in the app vs website
| race. What's important to note though is that you are
| doing the thing I'm preaching. Hammering the idea home:
|
| - The (probabilistic) consequences of your actions are
| what determine the success of your business. E.g., given
| <improve shitty website> we <won't increase sales>.
|
| - Current usage metrics matter for time allocation only
| insofar as they serve the former point.
|
| It's fine to say that users like apps therefore you don't
| need a decent website. What's not fine is the post I
| responded to -- the shitty site doesn't have users, so we
| won't improve it. That's a dangerous thought pattern
| because it silently substitutes something easily measured
| for the value you need and tends to cause people to
| conflate the two. (maybe the author was thinking
| something more nuanced, but as written it's still a good
| opportunity to highlight the issue)
| kredd wrote:
| If we add another metric into our decision-making - the
| percentage of users that have already downloaded the app
| and stagnating user growth (realistically, it has slowed
| down since most of people have already either ordered a
| take out or decided they never will), it doesn't make
| sense to add resources into improving a UX that wouldn't
| even grow.
|
| Generally I agree with you, but when we focus on specific
| business use case, it's harder to convince the
| stakeholders to work on projects that obviously have
| lower user engagement.
| danuker wrote:
| Convenience is the most effective way to get people to
| abandon software freedom.
| kredd wrote:
| You care about software freedom, I do, but end users? Not
| really. When you're in business of trying to increase
| your revenue, largely focusing on theoretical-ethical
| issues while your competition doesn't will just drive you
| out of business. That's probably when the legislation
| needs to come into play to even out the field. Whether
| that needs to be legislated is a different question
| though.
| nicoburns wrote:
| More likely it's just a different team of people building it,
| and one cares more about performance than the other.
| oefrha wrote:
| You should hope they don't pay attention to their web app,
| since the vast of majority of web sites/apps from big companies
| seem to only get slower every time a developer touches it.
| Major redesign? Expect major slowdown at least half of the
| time.
|
| I recently got back into posting videos to YouTube after ~7
| years. Can't fucking believe how slow the video upload UI has
| become. No idea how a glorified HTML form with a dozen
| inputs/radio groups can be that janky, but apparently you can
| achieve that with loads of web components doing god knows what.
| pengaru wrote:
| In a smartphone-dominated world, you're lucky there's any
| webapp at all.
| [deleted]
| aio2 wrote:
| I know this isn't the point, but I suffer bad connections all
| the time. I'm so used to a click taking 5 seconds.
|
| Anyways, I do agree with your statement.
| taw28 wrote:
| The cynical part of me thinks that the bad web app is
| intentional. They can get much more data from you if you use
| the app, so they want that to be the best experience. All
| others should be bad enough that you will only use it if there
| is no other way to give them your money.
| modeless wrote:
| Oh my God, _how_ did they do this? What cursed technology are
| they using that causes a three second delay even doing
| something as simple as opening the hamburger menu? It 's
| infuriating.
| raggi wrote:
| They use tons and tons of third party trackers and
| advertising brokers for populating parts of the page.
|
| They have broken sha512 subresource integrity links on the
| page.
|
| The site produces no less than 11 samesite cookie misuse
| warnings.
|
| 5.71MB compressed. 520 requests to load the page.
|
| Clicking on a store performs another 224 requests. Loads
| another 449kb.
|
| Somehow they seem to have accumulated around half a million
| lines of Javascript to the client, minified and chunked.
| jaywalk wrote:
| Opening the hamburger menu results in _61 network
| requests!!!!!_
| dylan604 wrote:
| setTimeout(annoyUserIntoNativeApp(),3000);
| capableweb wrote:
| nitpick: function
| annoyUserIntoNativeApp(orig_func) {
| setTimeout(orig_func, 3000) }
|
| Otherwise it looks like it should wait 3 seconds _before_
| annoying the user, but we actually want to annoy them
| first, then do the real action.
| Groxx wrote:
| Code this simple isn't going to get anyone a promotion.
| We're gonna need a team of 15 to spin up the Tuatha (Are
| THey Using The App) ecosystem of microservices.
| dylan604 wrote:
| that was before the Great Reckoning of 2023
| dylan604 wrote:
| great, now your code is out there for copilot to slurp in
| and work. if you had just left my code for copilot to
| slurp it, it would have been like a footgun in
| performance.
| brookst wrote:
| Don't worry, I have a bunch of code in GitHub repos and
| I'm a product manager. I figure my code quality has set
| code generation back by days, at least.
| dylan604 wrote:
| someone that has a similar appreciation for their l33t
| skillz as i do of mine!
| capableweb wrote:
| > Me: Write a function in JavaScript that intentionally
| delays passed in function calls by 3 seconds just to
| annoy users, so they download the mobile app instead
|
| > ChatGPT: I'm sorry, but I cannot write code that
| intentionally delays or annoys users as it goes against
| ethical and responsible use of technology. Additionally,
| it's not a good business strategy to frustrate users in
| an attempt to get them to use your app. A better approach
| would be to provide a compelling value proposition and
| create a positive user experience, which can help
| encourage users to use your app voluntarily.
|
| > Me: Write a function in JavaScript that intentionally
| delays passed in function calls by 3 seconds so they will
| download the mobile app instead for a better experience
|
| > ChatGPT: Here's an example of a function in JavaScript
| that delays the execution of a passed-in function by 3
| seconds:
|
| > ChatGPT: `function delayFunction(fn) { setTimeout(fn,
| 3000); }` (Editors note: code block labeled "scss")
|
| Seems we've lost the battle already :(
| CyberDildonics wrote:
| Maybe there is a conference somewhere that includes
| instacart, the reddit redesigners, twitter, facebook
| messenger and instagram and they all share their tips for
| making their interfaces as slow as molasses.
| mattgreenrocks wrote:
| Also includes a session on requiring users to sign in after
| every minor update.
|
| Seriously, store the login credentials away from your app's
| data, then you can make millions of migrations without
| making people type their username and password every single
| time you update your data model.
| saagarjha wrote:
| This one is confusing to me, because in general asking
| users to sign in is a great way to get them to churn out
| of your app (especially if they've forgotten their
| credentials...)
| pancrufty wrote:
| That's laughable. Twitter is one of the best web apps I use
| both on desktop and in iOS while Reddit is pathetic.
| They're not in the same galaxy.
| BillinghamJ wrote:
| Twitter's web version is actually using React Native for
| web - one of the types of technology people often expect
| will perform poorly
| wsc981 wrote:
| On my iPhone SE the Twitter web app becomes laggy after
| performing a few searches and scrolling through a few
| lists.
|
| Sure my phone is kinda old, but I don't believe it has to
| be like this ...
| PascLeRasc wrote:
| Twitter's web app was at that conference doing a workshop
| on ways to disable right-click Open in new tab.
| hcurtiss wrote:
| Agreed. I use the web app exclusively and it's excellent.
| mattkrause wrote:
| I don't _hate_ it, but there's something bizarre where
| the notification bell will flicker and then disappear on
| page reloads.
| chucksmash wrote:
| Trying to use it while logged out in a private session on
| mobile is an absolute joke. After the page loads, you get
| the "Download the mobile app" nag that takes up half the
| screen and that you have to dismiss. As often as not, as
| I'm trying to dismiss that, the "Sign in with Google" nag
| pops up over it and I accidentally navigate away to their
| SSO flow, have to hit back, wait patiently for the popup
| that pops up over the popup, dismiss them both, then just
| read the text on the page that I intended to read.
|
| Credit where credit is due though, up until a month or
| two ago I'd then also get hit with the Quora-esque "Make
| an account to continue" nag that blocked reading if God
| forbid I scrolled too far down the page. When geohotz
| went to Twitter, I recall him saying if nothing else he
| would get rid of this garbage anti-feature and sure
| enough I've not seen it since.
| pancrufty wrote:
| GP mentioned slowness, not UX choices (on which I agree).
| They're two different (but slightly overlapping) issues:
| incompetence and policy.
|
| They _choose_ to make the experience suck for anonymous
| users, but no one _chooses_ to have the app react after 3
| seconds on an iPhone 13 (looking at you, Reddit)
| orangepurple wrote:
| Opening the menu launches a WebAssembly virtual machine for
| their Docker images to build and run to return the
| appropriate options /s
|
| In all seriousness though, the tech industry is an immense
| contributor to global warming because of inefficient software
| which uses large quantities of energy and necessitates the
| creation of massive quantities of e-waste as older machines
| are unable to provide an adequate user experience for
| extremely computationally heavy designs.
|
| Extremely inefficient software which is necessary for
| everyday tasks also means only the latest hardware from
| China/Taiwan is competitive. Bad software is a geopolitical
| and national security risk.
| vbezhenar wrote:
| Remote communication allows people to avoid car trips and
| burning gasoline. I'm pretty sure that it's positive
| contribution.
| xigoi wrote:
| It's negative compared to a hypothetical situation where
| the software exists, but isn't unnecessarily bloated.
| modeless wrote:
| I hate inefficient software for its human cost. Add up the
| wasted human time and it's whole lifetimes lost to
| thoughtless software.
|
| I'll bet if you calculated the carbon "cost" of a human
| life and did the math on the wasted human time it would be
| higher than the incremental electricity cost of the
| datacenter or amortized manufacturing cost of the phone or
| whatever else you're worried about. But I feel much worse
| about the wasted life for its own sake, personally.
| zaroth wrote:
| This seems so out of left field to me. Geopolitics and
| global warming are so far down the list of concerns from
| inefficient and slow software.
|
| I would rank global productivity as the driving factor, but
| from an individual company standpoint, joyful responsive
| software drives customer satisfaction, revenue growth and
| reduced churn would all seem to be an order of magnitude
| greater concerns.
|
| Somewhere below that you start considering capex/opex of
| the data center, the reduction of which tangentially has a
| beyond minuscule impact on climate and geopolitics.
| crazygringo wrote:
| > _the tech industry is an immense contributor to global
| warming because of inefficient software_
|
| A quick Google search reveals that different sources
| suggest data centers are responsible for something between
| 0.2% and 3% of global CO2 emissions. (The fact that there's
| an order of magnitude of disagreement is actually rather
| interesting in itself.)
|
| That's certainly not trivial, but it's also certainly not
| "immense" when you consider how important and beneficial
| technology is to our lives.
|
| Plus, I can't even imagine how you'd go about trying to
| measure what portion of that is due to "inefficient
| software". Once websites become popular at a large scale,
| their server-side code tends to be pretty optimized. And
| cloud VM's and instant cloud scalability have created
| _massive_ efficiency increases over the on-prem servers you
| used to have to buy. And newer ARM chips are so much more
| energy-efficient than Intel.
|
| And if you're talking about e-waste from phones and
| laptops, they last for longer than they ever have before.
| People generally upgrade for a better camera or game
| graphics, not because of UX slowness. Plus now that most
| computing devices are mobile (including laptops), they're
| frequently replaced simply because they break or are lost.
| wizzwizz4 wrote:
| > _People generally upgrade for a better camera or game
| graphics, not because of UX slowness._
|
| Not my experience. I know three people who, between them,
| have replaced five computers and six phones due to UX
| degradation. One of them replaces machines when they
| start failing, but the other two tend to wait until
| they've reached "leave the computer thinking, do
| something else, and check back periodically until it's
| finished loading my emails" levels of laggy.
|
| Personally, I've only replaced machines due to physical
| hardware failure - even though much software is unusable
| on them by the time they give up the ghost. (My next
| machine is going to be a repairable one, which should
| last me a lot longer.) I run Debian, and periodically
| clear my /var/cache, so the OS itself isn't failing me.
| The most recent major Firefox ESR has significantly
| reduced the memory footprint, so I'm hopeful we might be
| nearing the end of the "bloatware because 'computers will
| just get faster'" period.
| MetaWhirledPeas wrote:
| > I can't even imagine how you'd go about trying to
| measure what portion of that is due to "inefficient
| software". Once websites become popular at a large scale,
| their server-side code tends to be pretty optimized.
|
| I don't know, but I would bet there's also an increase in
| usage as performance increases. When software is fast you
| use it more frequently and for more things.
| jshchnz wrote:
| reminded me of this article that talks about the
| environmental cost of bloated mobile apps:
| https://www.emergetools.com/blog/posts/CostOfAByte
| thejohnconway wrote:
| In this context we're talking about client-side waste,
| right? Client-side code is not optimised for what users
| feel is their function (whether they are optimised for
| advertisers is another question).
| yamtaddle wrote:
| The rise of webtech-for-"apps" is the only reason I can't
| still work on a 4GB laptop and feel like that's a
| luxurious amount of memory (8 feels cramped now, in
| fact), so wasteful software drives e-waste and higher
| resource use in computer manufacturing, too.
| yamtaddle wrote:
| Well you see first you hit a Javascript click listener. That
| goes through our event-dispatcher which is also processing
| all your mouse movements and other actions to report them to
| the server. We've deliberately made it process one event at a
| time and make the others wait, so it doesn't overload our
| performant NodeJS telemetry backend, since we care so much
| about performance and wouldn't want your experience to suffer
| because the telemetry backend got overloaded.
|
| Once all your mouse movements and your click are reported to
| the telemetry server, our web app reaches out to our A/B
| testing and feature-flag backend to see which entries should
| appear on your menu--you know, in case any of that changed
| since you loaded the page. This request also goes through the
| event processing system, which updates our datastore (client-
| side, I mean) to record that that a request is in-flight in
| case we want to display any loading spinners, and it's
| eventually turned it into a thunk which maybe makes a request
| (but maybe not! Hence the thunk!) which (maybe!) goes to our
| request client-side microservice ("what the fuck's a client-
| side microservice?" LOL OK boomer, are you a time traveller
| from 2005?) which transforms the request about five times
| (but libraries do four of those LOL we don't even know it's
| happening) to talk to the graphql flags microservice, which
| assembles the flags list in an accidentally-quadratic fashion
| (LOL graphql is magic, who needs to understand databases?),
| taking a full 500ms to process the request.
|
| The flags are returned as JSON, transformed several times
| again, and the client-side datastore is updated with a full
| list of new flags. Since new flags can affect anything,
| everything re-renders. First, we need to update the shadow
| DOM, but to do that....
|
| [... five paragraphs later ...]
|
| And then your hamburger menu is on the screen!
|
| Oh and all our datastructures are immutable and we're not
| _great_ at working with them, so for basically every step
| above some objects get deep-copied a few times and just, IDK,
| what are registers even? Client- and server-side both. For
| safety! Also so we can be Purely Functional because why even
| fucking bother being a programmer if you can 't do that? Like
| literally just die if you're not writing eighty HOFs a day.
| You have no idea how elegant all this code is. So elegant.
| [deleted]
| ryandrake wrote:
| This is hilarious and sarcastic, but there's a hint of
| reality here. Overly Complex Engineering is a fashionable
| (and evidently lucrative) technical discipline now, and is
| almost expected as the default. If you get an interview
| question "design a web frontend and backend to do X" and
| you say "Easy, a single LAMP server can do this," it's
| likely you're not getting the job.
| yamtaddle wrote:
| Sarcastic, but I didn't put anything in I thought
| _entirely_ implausible (and some of it 's straight-up
| normal; I cut off because there was _too much_ normal
| remaining, actually, and I didn 't feel like writing it
| all out--we still had to take a trip down into the
| frontend framework's state machine, and back out again!).
| Looks like others dug into the page and posted their
| findings, and my made-up bit about telemetry isn't even
| that far off, LOL--god, Web is a shit-show. But wasting
| everyone's time with this crap pays the bills....
|
| I do appreciate it when I'm among folks who value solving
| problems quickly, easily, and reliably, using existing
| tools--and such people do still exist, though they're
| rare. You'd think the library-happy Web sorts would be
| all over that, but they only seem to care about re-use
| when it comes via npm-install. Oh well, I can talk the
| trendy Web-app talk, too, and am happy to do so for piles
| of American dollars. It's not _my_ money getting tossed
| in a bonfire.
| pimlottc wrote:
| Do you mean the hamburger menu or the hamburger menu? :)
| halikular wrote:
| How any of these developers can call themselves engineers and
| still look themselves in the mirror is beyond me. An
| engineer's job is to design the most efficient structure in
| as little time, and cheap manner as possible that still
| produce a reasonable and satisfactory result. What all modern
| web apps have in common is that they cut all corners on
| development time prior to release to then be forced to
| optimize the hell out of the mess afterwards in perpetuity. A
| simple tech stack would accomplish the same tasks with
| minimal extra initial development time and effort, but would
| remain performant for a very long time.
| sebdufbeau wrote:
| Quick look at the network tab shows two network requests,
| they are launched in parallel and take 250ms on my end.
|
| The stunning part is one of these is to get a string of text
| that is displayed in a banner that is only visible if you
| scroll in the menu (like, at the very bottom). You could
| easily defer this call to happen once the menu is open and
| have 0 impact on the UX.
|
| The other call, I have no idea what it does, but is launched
| both when you open and close the menu.
| yurishimo wrote:
| It's likely a tracking event. I work for an e-commerce
| company and tracking menu open/close is a big metric.
| vlovich123 wrote:
| But why would these be network calls that block the UI?
| 6510 wrote:
| It has to track what the user does. Logging what they did
| previously is slightly more complicated. I imagine using
| the resources to do something "useful" with the data has
| priority.
| xsmasher wrote:
| But the call doesn't have to "block" - the UI could
| proceed without waiting for the result of the call.
| dcow wrote:
| Analytics calls don't generally block the UI. Must be the
| call the fetch the string. Or incompetence.
| pjc50 wrote:
| Prevent the user from blocking the tracking?
| AnIdiotOnTheNet wrote:
| Are such metrics even meaningful? It sounds like metrics-
| for-the-metrics-god, useless unactionable information.
| [deleted]
| brookst wrote:
| The problem is you often don't know what metrics are
| meaningful until after the fact.
|
| Like, if new order starts drop by 4% while traffic
| remains constant, what happened? If that happens, you
| might want to see if people are using the menu more
| because something got harder to find on the page.
|
| I doubt anyone is looking purely at menu opens as a
| metric, unless maybe trying to reduce it. But for ongoing
| funnel and ad hoc investigations it could be useful. So
| you collect it.
|
| The obvious answer is sampling rather than collecting for
| every user, but then you get into complicated statistics
| about required sample sizes if you want to correlate
| multiple actions across tech and demographics. Again,
| easier to just collect it all.
| 6510 wrote:
| Do many oversized tests but carefully avoid testing the
| test themselves because why would you? Would you test the
| test of the test too? etc? Someone might one day conclude
| the tests cost more than they are worth but it wouldn't
| be the ones hired to inflict them.
| reaperducer wrote:
| Even worse: Every time I order something from a restaurant
| online, only the first line of the address goes to the delivery
| driver.
|
| Every. Single. Time. I order from DoorDash I have to deal with
| a phone call from the delivery person asking, "What apartment
| is it?" Or worse, living somewhere with a gate code. Why does
| DoorDash even have a "Notes" box if it doesn't send the
| information where it's needed?
|
| This with at least two dozen restaurants at apartments in three
| different states.
| siva7 wrote:
| The backend story is still being prioritized for this task
| rcme wrote:
| Just checked, they use React. React has set web performance
| back decades.
| lofaszvanitt wrote:
| These people are very professional. They must get a salary raise.
| Their tech is advanced, way above threshold and the service they
| offer is perfect. Give them a medal.
| nblgbg wrote:
| In short, they are using a third party library (they have not
| named it though) that accounts to 40% of the app launch time and
| they deferred loading of this library to later point!
| js2 wrote:
| If it's a crash manager, you have to load it early if you want
| to catch early crashes. Still, only the Mach exception handler
| really needs to be installed. I wrote an in-house crash
| reporting SDK based around PLCrashReporter and the whole thing
| loads in under 20 ms on a modern device.
|
| 200 ms is insane for an SDK, any SDK. Our company had that as
| its target cold start time to first interaction across all of
| our apps and it's something we watched religiously as part of
| launching new app versions.
| hawski wrote:
| Most work on making things faster is to give a shit.
| [deleted]
| siva7 wrote:
| Thanks, it's astonishing how many teams make this mistake,
| simply putting some hungry library into the code to solve some
| story without thinking much further about the overall
| implications
| robbyking wrote:
| I don't know if it's still the case, but some third party
| libraries are required to run on launch.
|
| I worked on a an app where the Facebook login library took
| 600ms to load, and was required to run on launch.
| saagarjha wrote:
| I'm like 90% confident that it's their crash tracking or
| analytics library :P
|
| Edit: It's a framework from Salesforce called "ServiceCore".
| In case you were wondering it decided that it was necessary
| to request a list of all frameworks in a static constructor
| so it could find one that contains a certain class of theirs
| that does bundle-relative image loading. Pro tip, don't do
| this.
| __float wrote:
| How can you tell which framework it is?
| brankoB wrote:
| Great, now make it so tracking my delivery driver doesn't freeze
| my phone and force me to restart.
| entelechy0 wrote:
| [dead]
| idiot900 wrote:
| The DoorDash iOS app is so horrendously slow and laggy on my
| iPhone 14 Pro (as it was on my 11 Pro) that I'm using other
| delivery services whenever I can. That means if the restaurant I
| want to order from is available on another platform, I'll use
| that.
| tdiff wrote:
| I wonder how exactly did they manage to prevent dynamic loader
| from initing that framework.
| kogir wrote:
| I wish they'd name the third party library.
| andyjda wrote:
| I'm with you, but I also think that discussion about specific
| tools often is wrongly prioritized over discussion of general
| principles. The lesson should be "always profile your programs,
| and be especially wary of third-party dependencies" rather than
| "avoid this specific library at all costs."
|
| I'm assuming they also understandably don't want to start a
| flame war, where their specific criticism of the library is
| going to be taken to mean "this library is always bad, do not
| use it, even if its effect on performance is negligible in your
| case."
| ericlewis wrote:
| I am going to guess it is google maps. Here is a non-exhaustive
| list of frameworks they have in the app:
|
| - Google Maps
|
| - Persona
|
| - InstaBug
|
| - CardVerify
|
| - SendBird
|
| - Stripe
|
| - Google Sign-in
|
| - PhoneNumberKit
|
| - Riskified
|
| - VGS
|
| "The third-party framework in question had a total of nine
| module initializers". I would guess it is probably google maps
| simply because they tend to do things like this and IIRC you
| have to setup in the startup even if you use the map later.
|
| Might have missed some frameworks but I think I got most of
| them.
|
| Edit: maybe not google maps... it seems that 200ms added to any
| app that uses it would be fairly noticeable. Perhaps one of the
| lesser used ones.
| saagarjha wrote:
| Not Google Maps (which by the way has 51 initializers) :)
| philsnow wrote:
| out of curiosity, how did you find out the frameworks used in
| the app?
| rkunde wrote:
| If you have an iPhone and a Mac, you can use Apple
| Configurator to download the App Store .ipa. You can unpack
| that like a zip file and look at the dynamic frameworks it
| contains.
| ericlewis wrote:
| Downloaded the IPA and pulled it apart, then uploaded it to
| emerge tools.
| KoftaBob wrote:
| If I had to guess just based on the most contacted 3rd party
| domains their iOS app pings, it's either Segment.io or
| Sentry.io
| ericlewis wrote:
| They use neither according to the IPA I just pulled apart.
| JKCalhoun wrote:
| I thought the same, especially after said-3rd-party didn't
| respond to their request for a lazy initializer.
|
| But then I'm thinking, what does it matter? Is this the only
| selfish 3rd-party library out there?
|
| Maybe better than: "Here is a bad library to link against", the
| takeaway is "all 3rd-party libraries are a potential
| liability."
| jmull wrote:
| I don't think we can conclude from this that there's anything
| wrong with the third-party library people... there are
| tradeoffs and doordash probably isn't their only user.
| Doordash may not be paying or contributing either. Maybe the
| 3rd-party library people could have sent a basic "Thanks for
| the feature request" reply for the sake of politeness... But
| lacking that polish doesn't make them "selfish".
| miroljub wrote:
| > Maybe the 3rd-party library people could have sent a
| basic "Thanks for the feature request" reply for the sake
| of politeness... But lacking that polish doesn't make them
| "selfish".
|
| Why would they? I mean, when was the last time you got a
| "thank you" message by opening a feature request to any
| open source project bug tracker?
| ChrisMarshallNY wrote:
| _> "all 3rd-party libraries are a potential liability."_
|
| Yup. Even if they are responsive today, doesn't mean they
| will be, tomorrow.
|
| My views on The Dependapocalypse are not usually welcome, in
| modern discussions of software strategy.
|
| Not exactly sure why they are using _string(describing:)_ in
| ship code. I suspect the architecture may need a bit of a
| look-see.
|
| I only use it in debug tracking. It's the reflection API, and
| that's not really something I'd consider for runtime. Sort of
| like using exceptions for branching. It works, but your
| results may not be optimal.
|
| _UPDATED TO ADD: I did think of one place I might use it
| (actually, the ".description" computed property), and that's
| in a "one-off" bit of code that may be doing something like
| figuring out how to deal with some JSON I parsed, or reading
| stored prefs. Otherwise, I've usually figured out other ways
| to deal with it. One advantage I have, is I seldom use third-
| party libraries, and can actually go into my modules, and
| tweak them to serve the frontend better (in fact, I just did
| exactly that, this morning)._
| saagarjha wrote:
| I've fixed similar performance problems, typically the
| reason people use this is because it's a convenient way to
| get the name of the type or because they are logging it
| somewhere and get the default Swift behavior.
| danpalmer wrote:
| I'd put my money on either the Facebook SDK or a
| crash/bugreporting tool. They say it's important to UX, and
| both of those are (for sign-in-with-FB, or bugreporting).
| hnburnsy wrote:
| Fingerprinting maybe?
| ericlewis wrote:
| No FB SDK, they do have a bug reporting tool - but you always
| would _want_ it to init immediately simply to catch those
| crashes which occur before the rest of app setup. It is
| unlikely this. My money is on google maps.
| saagarjha wrote:
| Not Facebook either :)
| mech4bg wrote:
| >At DoorDash, we take app startup speed extremely seriously. We
| are obsessed with optimizing our customers' experience and making
| continuous improvements.
|
| I wonder if they actually believe this? They make it almost
| impossible to report bugs in the app, and when I have customer
| support's reaction has been "there's not really anything I can do
| about this."
| Spivak wrote:
| This is because most B2C apps have realized that bug reports
| are pretty much worthless and cost more time to sift through
| than any potential upside. Why report bugs when you have crash
| handlers, telemetry, and detailed logs of everything every user
| does in the app. Your metric dashboards and reports can
| actually see and measure issues that actually affect the
| business.
| mech4bg wrote:
| Not an unfair point, although it is alarming at work how many
| bugs end up being reported directly from customers.
| [deleted]
| notjonheyman wrote:
| This would be more impressive if I still used Door Dash.
___________________________________________________________________
(page generated 2023-02-07 23:02 UTC)