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

Recording and visualising the 20k system calls it takes to "import seaborn"

blog.mattstuchlik.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#41

Post by winrid »

josephg wrote: post #32
nonethewiser wrote: post #29

Earlier quoted context omitted.

Im curious what the orm misuse was because Python can obviously handle a lot higher loads than that. Perhaps the orm is to blame for offering some footgun. Or maybe the developer did something impossibly idiotic.

One big problem they had was that the system checked the user’s access permissions on every request. Access control in this application is quite complex, and so the access control code ended up issuing multiple queries and doing a lot of over fetching to do its job. (The classic ORM problem.) It turned out that this was also happening for all static assets. Oops. And the site is covered in very small images. Double o…

150 queries per page load is nothing. I'd check for missing indexes...

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#42

Post by bb88 »

GuestHNUser wrote: post #35
bb88 wrote: post #15

Earlier quoted context omitted.

Numpy is competitive with optimized C/C++. So even if it's running in a Jupyter notebook, it's still going to be insanely fast.

> Numpy is competitive with optimized C/C++ Can you cite a source/example for that? I cannot imagine an optimized C program that doesn't blow python with numpy out of the water. Even a poorly written C program is likely to be 2x faster simply because it doesn't have to round trip operations from C to python and back.

I feel like this is google-able, no?

I found some metrics after 30 seconds of googling.

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#43

Post by t8sr »

bb88 wrote: post #15
t8sr wrote: post #12

Earlier quoted context omitted.

Oh absolutely, for some tasks Python is amazing. I use Jupyter notebooks a lot, for example, and the flexibility is an incredible feature. It just worries me when I sometimes see those same Jupyter notebooks running in production, crunching 100s of terabytes of data. Maybe I’m wrong, but I didn’t get the impression everyone realizes exactly how wasteful that is. I guess AWS credits are easy to come by. One thing Goog…

Numpy is competitive with optimized C/C++. So even if it's running in a Jupyter notebook, it's still going to be insanely fast.

Numpy is fine. But people write a lot of complicated code to pull JSON from somewhere, transform it in Python, and write it to parquet somewhere else, for example. JSON, the dict type and parquet are all implemented in C, but a comprehension on top of a Python iterable is just gonna be pure Python “bytecode”. It has been my experience that rewriting such things in C++, or even Go or Java is an easy way to quickly save truly incredible amounts of compute.

A team I used to work with was forced to throw away a finished Python data pipeline that took them a year to build, because it cost more to run than the combined salaries of the team. And I really think if they’d had better intuition about Python’s performance under different scenarios, they could have saved a year of effort. This is why I feel it’s worth having frank discussions about trade offs when it comes to this language.

It’s incredibly useful, but people in the community aren’t clearly told about its limitations. (Especially wrt performance, but also maintainability.)

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#44

Post by [deleted] »

t8sr wrote: post #8
axchizhov wrote: post #4

Earlier quoted context omitted.

So, instead of printing a pretty plot in 2 lines of code, you will be... making these 20k syscalls yourself? You have such unusual hobby, my friend!

It doesn’t take 20k syscalls to print a plot, the 20k syscalls is for the import call. I would hope that drawing plots takes a lot less. To engage with your point: loading a dynamic library in a regular language takes significantly less than 20k syscalls. Probably 20-40 for C on Linux. Python is uniquely inefficient. On most plots comparing resource use by different languages, in order to even show python together wi…

[deleted]

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#45

Post by axchizhov »

t8sr wrote: post #8
axchizhov wrote: post #4

Earlier quoted context omitted.

So, instead of printing a pretty plot in 2 lines of code, you will be... making these 20k syscalls yourself? You have such unusual hobby, my friend!

It doesn’t take 20k syscalls to print a plot, the 20k syscalls is for the import call. I would hope that drawing plots takes a lot less. To engage with your point: loading a dynamic library in a regular language takes significantly less than 20k syscalls. Probably 20-40 for C on Linux. Python is uniquely inefficient. On most plots comparing resource use by different languages, in order to even show python together wi…

Well, duh. Seaborn is a plotting lib for research — you will probably make a couple of hundred calls to it in a week. In a week. After that, you will save your figures for the report and forget about your code. It's plainly obvious that you don't use it in a high load production scenario.

I just don't see how a person could spend 20 years using python and still can't figure out that you shouldn't hammer nails with a microscope.

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#46

Post by t8sr »

pdonis wrote: post #19
t8sr wrote: post #8

Earlier quoted context omitted.

It doesn’t take 20k syscalls to print a plot, the 20k syscalls is for the import call. I would hope that drawing plots takes a lot less. To engage with your point: loading a dynamic library in a regular language takes significantly less than 20k syscalls. Probably 20-40 for C on Linux. Python is uniquely inefficient. On most plots comparing resource use by different languages, in order to even show python together wi…

> the 20k syscalls is for the import call Yes, because you're importing a library that does a lot more than just print a plot. A purpose-built Python program that just printed the plot, nothing else, would need a lot less than 20k syscalls too.

You're missing the point - importing a module in other languages takes ~100x fewer system calls. It's a rare example of Python doing something that's mostly written in pure Python, rather than invoked via an FFI, and it shows some of the inefficiency of the language laid bare. That makes it an interesting case to study.

(Of course an import call in Python does a lot more, but the end result is roughly the same as calling `dlopen` in, e.g., Swift.)

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#47

Post by RetroTechie »

albertgoeswoof wrote: post #9

Today I asked a devops engineer to tell me how much time a long (3 seconds avg) api call was spending on database queries, application logic, and network etc. He couldn’t understand the request and instead opened up the azure console and recommended we increase the number cpu cores / memory if performance is an issue. I look at posts like this and cry.

> Today I asked a devops engineer (..) He couldn’t understand the request

"Engineer"?!? Given above description, that makes me cry.

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#48

Post by LorenzoGood »

bb88 wrote: post #42
GuestHNUser wrote: post #35

Earlier quoted context omitted.

> Numpy is competitive with optimized C/C++ Can you cite a source/example for that? I cannot imagine an optimized C program that doesn't blow python with numpy out of the water. Even a poorly written C program is likely to be 2x faster simply because it doesn't have to round trip operations from C to python and back.

I feel like this is google-able, no? I found some metrics after 30 seconds of googling.

Please post your citation for your claim.

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#49

Post by lights0123 »

nsm wrote: post #30

Related to this, if you set the env var `PYTHONPROFILEIMPORTTIME=1` or run python with `-X importtime`, it will print out the cumulative and self times to import various modules. There is then this neat tool to visualize the data. https://kmichel.github.io/python-importtime-graph/ Highly recommend to find the worst imports affecting your program startup time. In general, the python community values tend towards funct…

At the other extreme, checkpointing the whole process once all imports have been resolved and restoring it for every execution can be used for frequently-run tools: https://github.com/albertz/python-preloaded

Re: Recording and visualising the 20k system calls it takes to "import seaborn"

#50

Post by jononor »

t8sr wrote: post #43
bb88 wrote: post #15

Earlier quoted context omitted.

Numpy is competitive with optimized C/C++. So even if it's running in a Jupyter notebook, it's still going to be insanely fast.

Numpy is fine. But people write a lot of complicated code to pull JSON from somewhere, transform it in Python, and write it to parquet somewhere else, for example. JSON, the dict type and parquet are all implemented in C, but a comprehension on top of a Python iterable is just gonna be pure Python “bytecode”. It has been my experience that rewriting such things in C++, or even Go or Java is an easy way to quickly sav…

If they had done performance testing from the start they could have saved a year. A pipeline that has not been performance tested was in no way "finished". Performance is not something that can be tackled on later. In any language...
Post reply on HN