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

111–120 of 191 posts

Re: Python numbers every programmer should know

#111

Post by krior »

lifeisstillgood wrote: post #86
sjducb wrote: post #85

It’s missing the time taken to instantiate a class. I remember refactoring some code to improve readability, then observing something that was previously a few microseconds take tens of seconds. The original code created a large list of lists. Each child list had 4 fields each field was a different thing, some were ints and one was a string. I created a new class with the names of each field and helper methods to pro…

I went to the doctor and I said “It hurts when I do this” The doctor said, “don’t do that”. Edit: so yeah a rather snarky reply. Sorry. But it’s worth asking why we want to use classes and objects everywhere. Alan Kay is well known for saying object orientated is about message passing (mostly by Erlang people). A list of lists (where each list is four different types repeated) seems a fine data structure, which can b…

I mean it sounds reasonable to me to wrap the data into objects.

customers[3][4]

is a lot less readable than

customers[3].balance

Re: Python numbers every programmer should know

#113

Post by Scubabear68 »

thundergolfer wrote: post #48

A lot of people here are commenting that if you have to care about specific latency numbers in Python you should just use another language. I disagree. A lot of important and large codebases were grown and maintained in Python (Instagram, Dropbox, OpenAI) and it's damn useful to know how to reason your way out of a Python performance problem when you inevitably hit one without dropping out into another language, whic…

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.

Re: Python numbers every programmer should know

#115

Post by dekhn »

NekkoDroid wrote: post #89
dekhn wrote: post #81

Earlier quoted context omitted.

What exactly do you need 1ms instead of 14ms startup time in a shell startup? The difference is barely perceptible. Most of the time starting up is time spent seartching the filesystem for thousands of packages.

> What exactly do you need 1ms instead of 14ms startup time in a shell startup? I think as they said: when dynamically building a shell input prompt it starts to become very noticable if you have like 3 or more of these and you use the terminal a lot.

Ah, I only noticed the "shell startup" bit.

Yes, after 2-3 I agree you'd start to notice if you were really fast. I suppose at that point I'd just have Gemini rewrite the prompt-building commands in Rust (it's quite good at that) or merge all the prompt-building commands into a single one (to amortize the startup cost).

Re: Python numbers every programmer should know

#116

Post by IshKebab »

nutjob2 wrote: post #52
thundergolfer wrote: post #48

A lot of people here are commenting that if you have to care about specific latency numbers in Python you should just use another language. I disagree. A lot of important and large codebases were grown and maintained in Python (Instagram, Dropbox, OpenAI) and it's damn useful to know how to reason your way out of a Python performance problem when you inevitably hit one without dropping out into another language, whic…

> A lot of important and large codebases were grown and maintained in Python How does this happen? Is it just inertia that cause people to write large systems in a essentially type free, interpreted scripting language?

Someone says "let's write a prototype in Python" and someone else says "are you sure we shouldn't use a a better language that is just as productive but isn't going to lock us into abysmal performance down the line?" but everyone else says "nah we don't need to worry about performance yet, and anyway it's just a prototype - we'll write a proper version when we need to"...

10 years later "ok it's too slow; our options are a) spend $10m more on servers, b) spend $5m writing a faster Python runtime before giving up later because nobody uses it, c) spend 2 years rewriting it and probably failing, during which time we can make no new features. a) it is then."

Re: Python numbers every programmer should know

#117

Post by lifeisstillgood »

krior wrote: post #111
lifeisstillgood wrote: post #86

Earlier quoted context omitted.

I went to the doctor and I said “It hurts when I do this” The doctor said, “don’t do that”. Edit: so yeah a rather snarky reply. Sorry. But it’s worth asking why we want to use classes and objects everywhere. Alan Kay is well known for saying object orientated is about message passing (mostly by Erlang people). A list of lists (where each list is four different types repeated) seems a fine data structure, which can b…

I mean it sounds reasonable to me to wrap the data into objects. customers[3][4] is a lot less readable than customers[3].balance

Absolutely

But hidden in this is the failing of every sql-bridge ever - it’s definitely easier for a programmer to read customers(3).balance but the trade off now is I have to provide class based semantics for all operations - and that tends to hide (oh you know, impedance mismatch).

I would far prefer “store the records as plain as we can” and add on functions to operate over it (think pandas stores basically just ints floats and strings as it is numpy underneath)

(Yes you can store pyobjects somehow but the performance drops off a cliff.)

Anyway - keep the storage and data structure as raw and simple as possible and write functions to run over it. And move to pandas or SQLite pretty quickly :-)

Re: Python numbers every programmer should know

#118

Post by gcanyon »

IshKebab wrote: post #116
nutjob2 wrote: post #52

Earlier quoted context omitted.

> A lot of important and large codebases were grown and maintained in Python How does this happen? Is it just inertia that cause people to write large systems in a essentially type free, interpreted scripting language?

Someone says "let's write a prototype in Python" and someone else says "are you sure we shouldn't use a a better language that is just as productive but isn't going to lock us into abysmal performance down the line?" but everyone else says "nah we don't need to worry about performance yet, and anyway it's just a prototype - we'll write a proper version when we need to"... 10 years later "ok it's too slow; our options…

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?

Re: Python numbers every programmer should know

#119

Post by gcanyon »

As someone who most often works in a language that is literally orders of magnitude slower than this —- and has done so since CPU speeds were measured in double-digit megahertz —- I am crying at the notion that anything here is measured in nanoseconds

Re: Python numbers every programmer should know

#120

Post by andai »

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.)

Post reply on HN