I didn't tell anyone to optimize anything. I just posted numbers. It's not my fault some people are wired that way. Anytime I suggested some sort of recommendation it was to NOT optimize.
For example, from the post "Maybe we don’t have to optimize it out of the test condition on a while loop looping 100 times after all."
The literal title is "Python Numbers Every Programmer Should Know" which implies the level of detail in the article (down to the values of the numbers) is important. It is not.
It is helpful to know the relative value (costs) of these operations. Everything else can be profiled and optimized for the particular needs of a workflow in a specific architecture.
To use an analogy, turbine designers no longer need to know the values in the "steam tables", but they do need to know efficient geometries and trade-offs among them when designing any Rankine cycle to meet power, torque, and Reynolds regimes.
Good callout on the paper reference, but this author gives gives every indication that he’s dead serious in the first paragraph. I don’t think commenters are confused.
Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.
Having general knowledge about the tools you're working with is not a distraction, it's an intellectual enrichment in any case, and can be a valuable asset in specific cases.
How is it not general knowledge? How do you otherwise gauge if your program is taking a reasonable amount of time, and, if not, how do you figure out how to fix it?
In my experience, which is series A or earlier data intensive SaaS, you can gauge whether a program is taking a reasonable amount of time just by running it and using your common sense.
P50 latency for a fastapi service’s endpoint is 30+ seconds. Your ingestion pipeline, which has a data ops person on your team waiting for it to complete, takes more than one business day to run.
Your program is obviously unacceptable. And, your problems are most likely completely unrelated to these heuristics. You either have an inefficient algorithm or more likely you are using the wrong tool (ex OLTP for OLAP) or the right tool the wrong way (bad relational modeling or an outdated LLM model).
If you are interested in shaving off milliseconds in this context then you are wasting your time on the wrong thing.
All that being said, I’m sure that there’s a very good reason to know this stuff in the context of some other domains, organizations, company size/moment. I suspect these metrics are irrelevant to disproportionately more people reading this.
At any rate, for those of us who like to learn, I still found this valuable but by no means common knowledge
I'm not sure it's common knowledge, but it is general knowledge. Not all HNers are writing web apps. Many may be writing truly compute bound applications.
In my experience writing computer vision software, people really struggle with the common sense of how fast computers really are. Some knowledge like how many nanoseconds an add takes can be very illuminating to understand whether their algorithm's runtime makes any sense. That may push loose the bit of common sense that their algorithm is somehow wrong. Often I see people fail to put bounds on their expectations. Numbers like these help set those bounds.
You gauge with metrics and profiles, if necessary, and address as needed. You don’t scrutinize every line of code over whether it’s “reasonable” in advance instead of doing things that actually move the needle.
These are the metrics underneath it all. Profiles tell you what parts are slow relative to others and time your specific implementation. How long should it take to sum together a million integers?
But these performance numbers are meaningless without some sort of standard comparison case. So if you measure that e.g. some string operation takes 100ns, how do you compare against the numbers given here? Any difference could be due to PC, python version or your implementation. So you have to do proper benchmarking anyway.
I am currently (as we type actually LOL) doing this exact thing in a hobby GIS project: Python got me a prototype and proof of concept, but now that I am scaling the data processing to worldwide, it is obviously too slow so I'm rewriting it (with LLM assistance) in C. The huge benefit of Python is that I have a known working (but slow) "reference implementation" to test against. So I know the C version works when it produces identical output. If I had a known-good Python version of past C, C++, Rust, etc. projects I worked on, it would have been most beneficial when it came time to test and verify.
Sometimes it’s as simple as finding the hotspot with a profiler and making a simple change to an algorithm or data structure, just like you would do in any language. The amount of handwringing people do about building systems with Python is silly.
I agree - however, that has mostly been a feeling for me for years. Things feel fast enough and fine.
This page is a nice reminder of the fact, with numbers. For a while, at least, I will Know, instead of just feel, like I can ignore the low level performance minutiae.
“We didn’t have the expertise to build the thing we were building, got in way over our heads, and built a basic POC using legacy technology, which is fine.”
Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.
But the motions do change, at very slow tempos you can move basically one finger at a time, at faster tempos you have simultaneously overlapping motions.
On a trumpet? A clarinet? No, the motions don't simultaneously overlap. The fingering mechanics are slightly different at speed, but you would still start slow while using the higher speed mechanics and tonguing technique, not jump into high speed practice first.
No one is saying not to practice slow first. This advice is specifically for intermediate or advanced students who are putting a focus on developing speed specifically. Practice slow first, increase tempo slowly next, but when you hit a plateau, you need to add some repetitions that are well outside your comfort zone. You need to feel what it feels like to play fast, then clean it up.
It seems like this is a far more time efficient methodology to build speed on guitar, I do not know why it wouldn’t apply to other instruments like trumpet.
It didn't solve any of the issues it proclaimed to. And, if you look across open platforms (e.g. HomeAssistant) it has, comparatively, low uptake on available integrations because Matter is a vehicle for proclaimed interop by walled garden experts (e.g. Apple, Google, etc).
I've got several Matter smart plugs and a couple Matter smart bulbs.
They all were quick and easy to set up with their first Matter controller (an RPi4 running Home Assistant or an iPad with Apple Home), and quick and easy to add to whichever controller I didn't use as the first controller.
They all worked then without requiring me to get their manufacturer's proprietary app or make an account or anything like that.
Some needed a firmware update to support Matter 1.3, and so I had to use the manufacturer's app for that. Some also have proprietary functions and options (for example one of bulbs supports some kind of presence detection if you have at least two of those bulbs in the same room) so I might get the manufacturers app if I decide I want to use those functions.
Adding them to the manufacturer's app does not interfere with their use as Matter devices so if I do decide I want to use some of the proprietary stuff it doesn't break things.
1) If you have to use a manufacturers app for updates that's already falling into my point. 2) There are plenty of threads out there discussing manufacturers that leverage Matter but they force their own controller to be able to be used. A lot of these are together at builders as another revenue stream for them.
Finally... This [0] does a better job of explaining the issues with Matter. But, Matter is ultimately a joke. It was promoted as a standard by vendors nobody should trust for interoperability at this point.
It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.
The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.
