41–50 of 109 posts
Some interesting tidbits on python code and compilation performance 1) During AoC I mostly used cpython and numpy. One day my code was running too slow so I fired up pypy. It ran even slower. Turns out numpy and pypy do not play well together in terms of performance. 2) I use matlab in work, and had some code that was slower than I liked, despite efforts to profile and optimise. I used the coder tool to compile it to…
I'm learning Python. Do someone knows a resource to learn the well-known tricks for "fast" Python? A book, a website, a cheat sheet or even a MOOC or part of a MOOC?
I would advise against optimizing your Python programs for speed. Fighting against a language's nature never leads to good results, it's much easier and better to use a faster language if (or where) you need the speed. This is even more relevant if you are still learning the language. Focus on learning it, and leave arcane always changing implementation details for after you know it well.
"Python is Slow, And That's Fine, Because It's Fast Enough" At least this is honest. No matter what the script does, no matter how fast the libraries, the Python intepreter has a slow startup time. On multiple occasions I have seen people commenting on HN argue that Python is not slow. I think for these commenters Python is "fast enough". For others, like me, it may not be "fast enough". IOW, the question is not whet…
I don’t always know how fast will be fast enough when I start a project and the risk of needing a rewrite really puts me off Python.
I've been writing some python the last few days. Today I did something terrible. I like to believe it was out of wisdom rather than ignorance. I needed to do some nuanced bit manipulations, and so I built up a string of ascii 0's and 1's, sliced the string, and then converted back to integers. I worked on a codebase many years ago when I was an intern. That code would read frames off a CAN bus in a car. For some reas…
How about a list of integers:
$ txr
This is the TXR Lisp interactive listener of TXR 274.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
This could be the year of the TXR desktop; I can feel it!
1> (digits 37)
(3 7)
2> (digits 37 2)
(1 0 0 1 0 1)
3> (reverse *2)
(1 0 1 0 0 1)
4> (mapcar (op - 1) *3)
(0 1 0 1 1 0)
5> (poly 2 *4)
22
Earlier quoted context omitted.
I don’t always know how fast will be fast enough when I start a project and the risk of needing a rewrite really puts me off Python.
This is premature optimization right
I'm learning Python. Do someone knows a resource to learn the well-known tricks for "fast" Python? A book, a website, a cheat sheet or even a MOOC or part of a MOOC?
[1] https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpyth...
"Python is Slow, And That's Fine, Because It's Fast Enough" At least this is honest. No matter what the script does, no matter how fast the libraries, the Python intepreter has a slow startup time. On multiple occasions I have seen people commenting on HN argue that Python is not slow. I think for these commenters Python is "fast enough". For others, like me, it may not be "fast enough". IOW, the question is not whet…
This really depends on your perspective. Sure, it's a lot slower than running a native binary. But it's still fast enough for interactive tools that you run often. If you compare that to java tools, for example, which take seconds if not dozens of seconds to start (gradle, I'm looking at you!), python is far better.
Other than that, I think the python code is quite readable and understandable with the context provided in the post.
Very well written post!