Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
> Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Genuine question, is software performance really linear like that, that one can and should only fight the tightest bottleneck, one workload at a time? Never really sounded right.
It also sounds like the typical sleight of hand where the difficult bit is simply laundered a layer up, in this case the choice of what workload one investigates.
It can be. Sometimes you take a profile and there's a big smoking gun and nothing else matters.
Sometimes it's a lot of small things everywhere and you can pick up significant performance after a lot of small value fixes. In this case, caching wire data instead of structured data is almost one of these, because the contribution to response time for serving a cache hit is small... otoh it happens so often than a small improvement matters; but this is a pretty focused use case, you usually hit the many smalln improvement issue in a less focused application where there are many code paths.
Sometimes the whole code structure / data structures are so wrong, but it works and perf is bad and profiling will never tell you. This article is not that case; these data structures only needed refinement.
In many cases, yes. A software pipeline can only achieve as much throughput as its slowest stage, and much of the software we write can be modeled as a sequence of processing stages.
Notice rules are ordered. You don't optimize until you know you need it. They started with a data structure they though would be fine. Clearly it was fine since it worked and they decided it was later worth optimizing.
The existence of 1.1.1.1 speaks to a much larger design problem. If you want to talk about what should have been done, you need to step much, much further back.
I was surprised by this number too - and I’m pretty sure it’s a clever wording trick to inflate the percentage:
> equivalent of a 26% higher sales tax than premium credit card users shopping at the same store.
I do not think the sale price is increased by 26% - which doesn’t square with a 1% to 3% fee - I think they pay approximately 26% more in “sales tax” so you’re paying 26% more than the 7% tax.
I know that this is a popular point-of-view in the US, but your states and legislative processes are all very homogeneous in comparison. You guys mostly speak the same language, you have the same cultural touch points, you have a shared history, shared media, and mostly centralized power.
Your country looks more like Germany (and if you know your history, that's no coincidence) than it looks like the EU.
I think, at this point, most people in Europe broadly have the same language as their second language.
> Overall proficiency: According to data from the European Union, over 43% of the total EU population speaks English as a second language, making it the most widely spoken non-native tongue across all 24 non-Anglophone countries in the bloc.
In theory, true. In practice, state independence has been dead for the better part of a century.
The 10th amendment has been eviscerated by the courts. By a strict reading of its relatively simple language, most of what the federal government does is unconstitutional.
Today, USA is unabbreviated as the “United States of America”, but the country was founded as the “United States for Anerica”.
As such, I am strongly in favor of returning to our former glory by stripping the federal government of most of its power and transferring it to the states.
I am also wise enough to know that will never happen without a long and bloody revolution, and I am okay with that given the lived reality that has defined my life.
We live in tyranny. You may not feel the rolling boil of the water that surrounds you, my fellow Americans, but make no mistake: your goose is cooked.
> country was founded as the “United States for Anerica”.
Do you have actual sources for that?
(Funny thing, I googled the phrase in quotes, did not realize the misspelling, and was a bit frustrated that the only result was this comment on HN...)
> but the country was founded as the “United States for Anerica”.
This is simply incorrect, it has been the United States of America since the Declaration itself where it states:
> We, therefore, the Representatives of the united States of America, in General Congress, Assembled,
Add in the function of the senate and the ongoing public perception of it, and as/if the senate is neutered by populist parties (MAGA/DSA) as they intend to also do with the courts, the argument that the states are sovereign (and they are by definition and constitutional agreement) becomes more and more practically useless, unfortunately (in some ways).
I'm not anti-federal government or anything but clearly we can see that there are issues in how the federal government has become so powerful and yet we're beholden to these two big-tent political parties leaving folks across the various states unhappy with decrees from Washington. Don't like Donald Trump's power over you? Maybe the federal government shouldn't have that power then?
Given what the states use their current power to do, I'm pretty fine with it so long as the party I'm like is in control of the federal government. If the last ten or so years of politics have taught us anything it's good to be on top with the tyrants, I guess.
And EU does it with VAT-OSS scheme which was also separate in each country before. There's just no will to do this with EPR because there's too much money and lobbying power in the recycling cartel.
The funny thing is that when the EU introduced these new VAT rules then it screwed over small and microbusinesses as well. It took them years to implement a minimum threshold for VAT (which every reasonable country has, but somehow EU rules did not).
I’d take this even further and say most programmers are incapable of building authoritarian software; where the client is subservient to the server by default.
Wrapping an interrogation in a polite "just to clarify" and demanding point estimates and error bounds on a generalization is weaponized pedantry designed to derail the thread into an impossible burden of proof.
It is fair to question the framing "many wealthy think the poor are lazy" because what the audience actually hears is "the majority of the wealthy think the poor are lazy (and other people don't think that)" because otherwise the sentence wouldn't have singled out the wealthy.
Is it really the majority? And if it is, is that belief limited to the wealthy or do the middle class also think that? What do the poor think?
(1) just to clarify isn’t meant to be polite, I’m trying to get GP to clarify his belief
(2) I don’t care about citations - I want GP to clarify his belief
(3) GP is using something similar to a Motte and Bailey to make a generalized statement about a group of people. They can argue against all wealthy people and retreat to “I didn’t mean all” with any argument that lands, without sacrificing the castle. This is a commonly used tactic when making generalizations about racial and social groups.
I think it's easy to see: (1) A simplified variation of it is true (namely, that if effort1 > effort2 then outcome(env, effort1) >= outcome(env, effort2) for any fixed environment env); (2) It flatters those who have achieved high outcomes, regardless of how much effort they put in.
I always add some jitter but never actually had a problem where it would have been relevant. Recently I added it to a project where others also see it (not just a hobby thingy but something at work) and I was wondering if it would look silly, like premature optimisation. I looked on Wikipedia for how established the practice is and it barely gets a sentence... with no reference.
Do you know of a documented instance where it would have helped?
This doesn't answer your question, but I faced an issue where an application had to retry if things failed and I ended up with the "thundering herd" problem and introduced jitter without knowing it was a relatively standard practice.
I felt dirty implementing such a solution (introducing randomness for the sake of randomness is off-putting), but it worked. It wasn't until a while later that I even heard the term "jitter" in this context and realized this was a pretty decent solution for this kind of problem.
Regardless, if you're going to introduce something where adding jitter is appropriate, I'd just just add jitter. It's not premature optimization; it's an essential part of that kind of functionality.
It’s not hard to get started, it’s a case of adding small amounts of randomness.
If you have, say, a long poll then kick off all users due to a deploy or error (or a broadcast message) then you can have a situation where you’ve got a huge clustering of connections at 1 minute, which spreads very slowly out as real life issues give you jitter for free. You can avoid this or at least return to normal much quicker by adding some jitter.
It might happen if all your users back off at the same rate too, if the clustering causes a bunch of errors. Error -> lots reconnect 1 minute after -> fail -> lots reconnect 2, 4…
More likely to occur in cases where there’s a way you can have people all connecting at the same time - synchronisation to a real world event is one case and then connecting again at the same time after.
You have thousands of users connected to a chat via websockets to a small cheap server that can just handle the load. Server has a hiccup, all clients disconnect, server comes back, all clients reconnect at once. Server can’t handle the load.
Downstream database of our edge serverless platform went down. A tonne of requests failed all at once. Every service in the microservice request path, and the client, had their own retry policy.
Clients all retried at the same time. Retries amplified in our microservice graph (1 request at the front door ended up with like 10s of retries internally as each downstream microservice along the path retried requests). Request queues backed up and couldn’t drain fast enough. Clients all timed out at roughly the same time. All waited the same time. All retried again at the same time.
It was a pulsing thundering herd of many hundreds of thousands of requests at the front door that was amplified by internal retries.
Had to tune up load shedding to 100% after the database outage was mitigated until the backend recovered then tune it down in increments to restore service.
Added jitter to clients and turned off retries on the serverless platform.
Exactly, without jitter the thundering heard problem turns into trying to escape a small island with a small boat and big waves hitting the shore problem. You can never fully recover before you get smashed again.
Even if you're operating at a scale where thundering herd won't crash your service, introducing exponential backoff + jitter to your retries also helps when you're just viewing the logs. Massively reduces log spam when you make changes.
If you’re talking about internet clients, I think the real world provides sufficient jitter. If you’re talking about a fleet of clients on your 10gbps network, jitter might be useful.
I've had to simulate jitter recently to reproduce a memory spike in a go app using traffic control (tc). have you observed how your app works under jittery network?
reply