4 ms·

Making ast.walk 220x Faster

112 points by palashawas 4mo ago

123rust123 4mo ago
[flagged]
- adhami 4mo ago
  only because I'm too lazy to learn how to write C with Python, if anything Rust wasn't helpful with all of those unsafes
  - mananaysiempre 4mo ago
    You’d have to spend a bit of time picking apart your arguments and releasing stuff on early error returns, but otherwise the Python/C API is completely banal and doesn’t really have much to learn. It might be worth the time to poke at it at some point to assure yourself this is the case. (Or you could switch to C++ and use pybind11, but now you’re just switching from one quite complex and somewhat off-putting language to another really complicated and very ugly one, so the win is less clear.)
westurner 4mo ago
Could this ast.sprint ast.walk optimization make libCST or bandit faster? https://news.ycombinator.com/item?id=39111747 https://news.ycombinator.com/item?id=39111747 libCST: https://github.com/Instagram/LibCST https://github.com/Instagram/LibCST bandit: https://github.com/PyCQA/bandit https://github.com/PyCQA/bandit Links to codemod tools; "Baby Steps into Genetic Programming" https://news.ycombinator.com/item?id=43617655 https://news.ycombinator.com/item?id=43617655
- westurner 4mo ago
  AST: Abstract Syntax Tree FST: Full Syntax Tree CST: Concrete Syntax Tree Comment preservation is a feature
- adhami 4mo ago
  it's possible! although many of the constraints in this blog were because we wanted to work with ast module in Python. If we were allowed to create our own types, we can do so much better. I think ruff has an even faster walk by those standards. It seems bandit is using some decent optimizations already, looking at the `@test.checks("Call")` seems like they already captured some easy wins. The largest win honestly would be using the same ast.walk for multiple rules, which we also did, but not mentioned in the blog.
  - westurner 4mo ago
    ruff probably does. Docs for ruff_python_ast: https://docs.rs/littrs-ruff-python-ast/latest/ruff_python_ast/ https://docs.rs/littrs-ruff-python-ast/latest/ruff_python_as... src: ruff/crates/ruff_python_ast: https://github.com/astral-sh/ruff/tree/main/crates/ruff_python_ast https://github.com/astral-sh/ruff/tree/main/crates/ruff_pyth... ast.toml, generate.py, Cargo.toml, src/ https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_ast/ast.toml https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth... Just rewrote docutils and myst-md-parser in rust with byte-for-byte equivalent output the other day; as westurner/dsport/src/docutilsrs and sphinxdocrs and so on. Pygmentsrs required fancy-regex because rust regex is linear. rstest and cargo-insta helped. PyCQA/docformatter https://github.com/PyCQA/docformatter https://github.com/PyCQA/docformatter and https://github.com/PyCQA/doc8 https://github.com/PyCQA/doc8 would be useful in rust, too. This from the other day: "A benchmark for catching when code doesn't do what its documentation claims"; docs fidelity evals https://news.ycombinator.com/item?id=48530786 https://news.ycombinator.com/item?id=48530786
eska 4mo ago
I appreciate that you first tried to optimize the original Python code. Idiomatic Python is unfortunately disappointingly slow and not so interesting to compare to.
- jerf 4mo ago
  I often use the rough approximation that Python is 40-50x slower than C. This is what you'll see in the benchmarks. The truly rough thing about Python though is that that is the speed when the code is being written to a benchmark. It is really, really easy to write Python that is multiples slower than that when not writing to a benchmark and just trying to get work done without hyperoptimizing. I did some testing of Python [1] to back some other commentary I was making that compared the time it took to set an attribute repeatedly on a particular instance of an empty class to the time it took to setting it on a subclass of a subclass of a class that had a property setter that was wrapped by a decorator. The latter was about 4.6 time slower than the direct attribute setting, which was itself already ~100x slower than an attribute setting in a static language. And it's not like a three-deep nested class with a property wrapped by a decorator is all that absurd in Python or anything. That's a completely normal case, not some absurd example I made up to skew the test. In practice the 40-50x number is more lower bound than what you can count on. If you are actually using Python's features I think you can easily score another order of magnitude slower without anything jumping out at you as being an obviously bad idea. [1]: https://jerf.org/iri/post/2024/not_about_python_addendum/ https://jerf.org/iri/post/2024/not_about_python_addendum/
  - colechristensen 4mo ago
    A while back I had claude implement something, I don't quite remember what it was, but it chose Python. It was going to take hours. I told it to rewrite it in Rust and it was > 300000x faster. This is without any optimization or prompting particularly about performance, a short one shot lift. echo "Python sucks, use something else when you can" >> ~/CLAUDE.md Python was cool in 2005 in academia IT, all the rage in startup 2012. These days...
  - elevation 4mo ago
fwip 4mo ago
I wonder if these lints could have been expressed as semgrep rules?
bionhoward 4mo ago
It’s amazing how much Python punishes you for modularizing your code
ozgrakkurt 4mo ago
"AI reflex-app builder" slop alert
anitil 4mo ago
I really enjoy making Python faster. I feel like the sweet spot for me is proving a concept with the dumbest possible implementation to show that something would work, and then using that as a comparison implementation to prove that later improvements match the results of the dumb, obviously correct implementation.
teo_zero 4mo ago
The second part, where it says that Rust is faster than Python, is so obvious than doesn't deserve any further comments. What I found interesting, is that idiomatic Python, with generators and all, can be so much worse than "C-style" Python, if you will pardon that term. It's a pity many kids are taught Python before C...
- Loranubi 4mo ago
  I still recommend to use idiomatic Python though. If you like C-style Python, you can use Cython and get a performance boost at the same time.

112 points by palashawas 4mo ago

123rust123 4mo ago

[flagged]

adhami 4mo ago
only because I'm too lazy to learn how to write C with Python, if anything Rust wasn't helpful with all of those unsafes
- mananaysiempre 4mo ago
  You’d have to spend a bit of time picking apart your arguments and releasing stuff on early error returns, but otherwise the Python/C API is completely banal and doesn’t really have much to learn. It might be worth the time to poke at it at some point to assure yourself this is the case. (Or you could switch to C++ and use pybind11, but now you’re just switching from one quite complex and somewhat off-putting language to another really complicated and very ugly one, so the win is less clear.)

westurner 4mo ago

Could this ast.sprint ast.walk optimization make libCST or bandit faster? https://news.ycombinator.com/item?id=39111747 https://news.ycombinator.com/item?id=39111747 libCST: https://github.com/Instagram/LibCST https://github.com/Instagram/LibCST bandit: https://github.com/PyCQA/bandit https://github.com/PyCQA/bandit Links to codemod tools; "Baby Steps into Genetic Programming" https://news.ycombinator.com/item?id=43617655 https://news.ycombinator.com/item?id=43617655

westurner 4mo ago
AST: Abstract Syntax Tree FST: Full Syntax Tree CST: Concrete Syntax Tree Comment preservation is a feature
adhami 4mo ago
it's possible! although many of the constraints in this blog were because we wanted to work with ast module in Python. If we were allowed to create our own types, we can do so much better. I think ruff has an even faster walk by those standards. It seems bandit is using some decent optimizations already, looking at the `@test.checks("Call")` seems like they already captured some easy wins. The largest win honestly would be using the same ast.walk for multiple rules, which we also did, but not mentioned in the blog.
- westurner 4mo ago
  ruff probably does. Docs for ruff_python_ast: https://docs.rs/littrs-ruff-python-ast/latest/ruff_python_ast/ https://docs.rs/littrs-ruff-python-ast/latest/ruff_python_as... src: ruff/crates/ruff_python_ast: https://github.com/astral-sh/ruff/tree/main/crates/ruff_python_ast https://github.com/astral-sh/ruff/tree/main/crates/ruff_pyth... ast.toml, generate.py, Cargo.toml, src/ https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_ast/ast.toml https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth... Just rewrote docutils and myst-md-parser in rust with byte-for-byte equivalent output the other day; as westurner/dsport/src/docutilsrs and sphinxdocrs and so on. Pygmentsrs required fancy-regex because rust regex is linear. rstest and cargo-insta helped. PyCQA/docformatter https://github.com/PyCQA/docformatter https://github.com/PyCQA/docformatter and https://github.com/PyCQA/doc8 https://github.com/PyCQA/doc8 would be useful in rust, too. This from the other day: "A benchmark for catching when code doesn't do what its documentation claims"; docs fidelity evals https://news.ycombinator.com/item?id=48530786 https://news.ycombinator.com/item?id=48530786

eska 4mo ago

I appreciate that you first tried to optimize the original Python code. Idiomatic Python is unfortunately disappointingly slow and not so interesting to compare to.

jerf 4mo ago
I often use the rough approximation that Python is 40-50x slower than C. This is what you'll see in the benchmarks. The truly rough thing about Python though is that that is the speed when the code is being written to a benchmark. It is really, really easy to write Python that is multiples slower than that when not writing to a benchmark and just trying to get work done without hyperoptimizing. I did some testing of Python [1] to back some other commentary I was making that compared the time it took to set an attribute repeatedly on a particular instance of an empty class to the time it took to setting it on a subclass of a subclass of a class that had a property setter that was wrapped by a decorator. The latter was about 4.6 time slower than the direct attribute setting, which was itself already ~100x slower than an attribute setting in a static language. And it's not like a three-deep nested class with a property wrapped by a decorator is all that absurd in Python or anything. That's a completely normal case, not some absurd example I made up to skew the test. In practice the 40-50x number is more lower bound than what you can count on. If you are actually using Python's features I think you can easily score another order of magnitude slower without anything jumping out at you as being an obviously bad idea. [1]: https://jerf.org/iri/post/2024/not_about_python_addendum/ https://jerf.org/iri/post/2024/not_about_python_addendum/
- colechristensen 4mo ago
  A while back I had claude implement something, I don't quite remember what it was, but it chose Python. It was going to take hours. I told it to rewrite it in Rust and it was > 300000x faster. This is without any optimization or prompting particularly about performance, a short one shot lift. echo "Python sucks, use something else when you can" >> ~/CLAUDE.md Python was cool in 2005 in academia IT, all the rage in startup 2012. These days...
- elevation 4mo ago

fwip 4mo ago

I wonder if these lints could have been expressed as semgrep rules?

bionhoward 4mo ago

It’s amazing how much Python punishes you for modularizing your code

ozgrakkurt 4mo ago

"AI reflex-app builder" slop alert

anitil 4mo ago

I really enjoy making Python faster. I feel like the sweet spot for me is proving a concept with the dumbest possible implementation to show that something would work, and then using that as a comparison implementation to prove that later improvements match the results of the dumb, obviously correct implementation.

teo_zero 4mo ago

The second part, where it says that Rust is faster than Python, is so obvious than doesn't deserve any further comments. What I found interesting, is that idiomatic Python, with generators and all, can be so much worse than "C-style" Python, if you will pardon that term. It's a pity many kids are taught Python before C...

Loranubi 4mo ago
I still recommend to use idiomatic Python though. If you like C-style Python, you can use Cython and get a performance boost at the same time.