Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python numbers every programmer should know

mkennedy.codes

Post reply on HN
Print view View original

181–190 of 191 posts

Re: Python numbers every programmer should know

#181

Post by Quothling »

fooker wrote: post #43
Quothling wrote: post #41

Earlier quoted context omitted.

Why? I've build some massive analytic data flows in Python with turbodbc + pandas which are basically C++ fast. It uses more memory which supports your point, but on the flip-side we're talking $5-10 extra cost a year. It could frankly be $20k a year and still be cheaper than staffing more people like me to maintain these things, rather than having a couple of us and then letting the BI people use the tools we provid…

> you need to know these numbers on Python to know when to actually build something in C People usually approach this the other way, use something like pandas or numpy from the beginning if it solves your problem. Do not write matrix multiplications or joins in python at all. If there is no library that solves your problem, it's a great indication that you should avoid python. Unless you are willing to spend 5 man-ye…

> People usually approach this the other way, use something like pandas or numpy from the beginning if it solves your problem.

That is exactly how we approach it though. We didn't start out with turbodbc + pandas, it started as an sql alchemy and pandas service. Then when it was too slow, I got involved, found and dealth with the bottle necks. I'm not sure how you would find and fix such things without knowing the efficiency or lack there of in different parts of Python. Also, as you'll notice, we didn't write ur own stuff, we simply used more efficient Python libraries.

Re: Python numbers every programmer should know

#182

Post by HenriTEL »

The goal of the article is not to know the exact numbers by heart, duh!

Care about orders of magnitude instead, in combination with the speed of hardware https://gist.github.com/jboner/2841832 you'll have a good understanding of how much overhead is due to the language and the constructs to favor for speed improvements.

Just reading the code should give you a sense of its speed and where it will spend most time. Combined with general timing metrics you can also have a sense of the overhead of 3rd party libraries (pydantic I'm looking at you).

So yeah, I find that list quite useful during the code design, likely reduce time profiling slow code in prod.

Re: Python numbers every programmer should know

#183

Post by andai »

kristianp wrote: post #148
andai wrote: post #120

The one I noticed the most was import openai and import numpy. They're both about a full second on my old laptop. I ended up writing my own simple LLM library just so I wouldn't have to import OpenAI anymore for my interactive scripts. (It's just some wrapper functions around the equivalent of a curl request, which is honestly basically everything I used the OpenAI library for anyway.)

I have noticed how long it takes to import numpy. It made rerunning a script noticably sluggish. Not sure what openai's excuse is, but I assume numpy's slowness is loading some native dlls?

OpenAI I haven't used in years but originally it would import many heavy libraries like I believe scikit-learn, and iirc they only used it for the cosine similarity formula for their embeddings function (lol).

Re: Python numbers every programmer should know

#184

Post by thundergolfer »

tialaramex wrote: post #155
TacticalCoder wrote: post #152

Earlier quoted context omitted.

> ... a function O(10_000) times in a hot loop O(10_000) is a really weird notation.

Generously we could say they probably mean ~10_000 rather than O(10_000)

I meant it as an order-of-magnitude notation, so means more like 10,000-90,000. Eg. calling the function 3,000 times is OK, but 30,000 is too much. Odd notation, yes, but I've picked it up somewhere along the way.

Re: Python numbers every programmer should know

#185

Post by Scubabear68 »

HenriTEL wrote: post #179
mrguyorama wrote: post #174

Earlier quoted context omitted.

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results. 3 times. This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down. Turns out, when you use programming languages that are fit for purpose, you don't have to…

Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.

Yep.

Except when it’s not I/O.

Re: Python numbers every programmer should know

#186

Post by [deleted] »

HenriTEL wrote: post #156
Scubabear68 wrote: post #113

Earlier quoted context omitted.

No. Python’s issue is that it is incredibly slow in use cases that surprise average developers. It is incredibly slow at very basic stuff, like calling a function or accessing a dictionary. If Python didn’t have such an enormous number of popular C and C++ based libraries it would not be here. It was saved by Numpy etc etc.

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

[deleted]

Re: Python numbers every programmer should know

#187

Post by igiveup »

mrguyorama wrote: post #174
HenriTEL wrote: post #156

Earlier quoted context omitted.

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results. 3 times. This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down. Turns out, when you use programming languages that are fit for purpose, you don't have to…

22ns might be about 100 processor instructions. Somehow I doubt that any programming language can parse 50 strings in 100 instructions, let alone with naive code.

Re: Python numbers every programmer should know

#188

Post by gcanyon »

IshKebab wrote: post #175
gcanyon wrote: post #118

Earlier quoted context omitted.

What language is “just as productive but isn't going to lock us into abysmal performance down the line”? What makes that language not strictly superior to Python?

Typescript, C#, Go, Rust. I'd say they are almost strictly superior to Python, but there are some minor factors why you might still choose Python over those. E.g. arbitrary precision integers, or the REPL. Go is a bit tedious and Rust is harder to learn (but productive once you have). But overall they would all be a better choice than Python. Yes even for startups who need to move fast.

I say this out of genuine surprise, not judgment -- I never would have guessed that native Typescript is significantly faster than native Python. To be fair, I don't know if "significantly" is justified. I get that Typescript is typed (heh) and Python is not, but compared to my daily driver language (also not typed) Python is so much faster that I subconsciously think of typing as not being the major performance unlock. But I guess once you optimize the rest, typing is (nearly) the final boss of performance.

Re: Python numbers every programmer should know

#189

Post by oofbey »

thundergolfer wrote: post #184
tialaramex wrote: post #155

Earlier quoted context omitted.

Generously we could say they probably mean ~10_000 rather than O(10_000)

I meant it as an order-of-magnitude notation, so means more like 10,000-90,000. Eg. calling the function 3,000 times is OK, but 30,000 is too much. Odd notation, yes, but I've picked it up somewhere along the way.

I think it follows naturally from speech. People say "order ten thousand" pretty naturally. Big-O notation is often vocalized as "order". But technically it's a a clash of ideas when written that way.

Re: Python numbers every programmer should know

#190

Post by mrguyorama »

igiveup wrote: post #187
mrguyorama wrote: post #174

Earlier quoted context omitted.

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results. 3 times. This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down. Turns out, when you use programming languages that are fit for purpose, you don't have to…

22ns might be about 100 processor instructions. Somehow I doubt that any programming language can parse 50 strings in 100 instructions, let alone with naive code.

You are right.

I have said something very wrong. Java may be fast but it isn't magic.

What I claimed is not possible and I should have realized that.

I can not correct my previous claim. I wish HN had longer edit windows and I wish HN allowed you to downvote older comments.

I cannot erase this wrong info

Post reply on HN