cython for performance

[kodonnell]

I'm currently in a try-to-optimize-static-analysers mood, and I'm wondering whether we could Cythonise this? Here's an example for astroid where I basically change no code, and just compile it with cython for a 20% performance improvement. There's more relevant discussion in that PR about other options too.

Thoughts? I imagine parso is pretty performance critical (jedi-vim etc.), but if not, then there's not much point. Especially if you don't want to depend on users installing Cython.

If you're interested and can point to a standard performance test case, I can submit a PR like the above for you to look at, including quantified performance improvements.

[davidhalter]

I personally am very aware of CPython's performance issues (and PyPy doesn't solve it for this project, unfortunately). The problem is that 20% is just not worth the effort and ongoing maintenance IMO.

I'm thinking a lot about rewriting this piece of software in Rust - it's basically just a matter of time and my own resources. If I had enough spare time, I would just do it. Such a rewrite would probably make it 100%-1000% faster.

So for now, I won't accept a Cython solution, simply because I don't want to maintain it.

[blueyed]

So for now, I won't accept a Cython solution, simply because I don't want to maintain it.

Just out of curiosity: does this imply that if @kodonnell would commit to maintaining it, it might be considered?

[kodonnell]

The problem is that 20% is just not worth the effort and ongoing maintenance IMO.

I'd like to clarify that 20% is gained from essentially zero code changes - please see the PR:

(And those minimal changes are either gitignore/setup.py or because astroid uses monkey patching of methods, if I remember rightly, which requires a decorator in Cython.) So I don't think there'd be much maintenance burden at all. And you'd get 20% (or more).

If you did some naive Cython in performance critical areas (e.g. cdef int i in a for i in x loop), then you might get e.g. 1,000% performance gains (i.e. 10x faster) - for very little maintenance burden (as the code would still essentially be unchanged, and any maintenance - e.g. changing logic or whatever - would have to be done anyway ... put another way you wouldn't have to keep changing cdef int i). If you did some serious Cythonising, to the point where you did get a maintenance burden (i.e. you've got some native C stuff, most of the code is cythonised as opposed to just bottleneck), then you might be looking at 10,000% performance gains (i.e. 100x faster). Those numbers depend a lot on what's actually going on under the hood, but it's indicative - it could even be more.

So I think the question is more:

• is 20% with no maintenance burden worth it?
• is 10,000% with a high maintenance burden worth it?

Re rust - I don't know rust, but I suspect you might be limiting community contributions, as you'd need people who know rust and python. You might want to compare that scenario with e.g. the minimal maintenance scenario above - a 10x speedup and code that can still be easily contributed to by the current contributor base etc.

Again, no promises on what Cython will actually offer (as maybe all the legwork is already done by C-optimised libs anyway). If there's serious interest (i.e. @davidhalter changes his mind) then I'm willing to:

• do a naive PR (like the linked on) with "no" code changes
• profiling and basic cython optimising (largely just cdef's etc.) and see how much performance gain we get.

Just out of curiosity: does this imply that if @kodonnell would commit to maintaining it, it might be considered?

I can definitely rule out committing to any serious Cythonizing - as I don't think it's a good idea, I don't have those skills, and it'd mean I'd be solely responsible, etc. I think the best idea is either the naive (20% speedup above) or trivial (1000% speedup above) and never going past the point that would hinder other contributors. (OK, except if there was e.g. one tiny function, that converting fully would result in a further 10x speedup, and that will never need to be updated, etc. etc.) But - can start small, and see if it's even worth it - maybe the gains will be minimal, as above.

[kodonnell]

@davidhalter, aside from the above, I just thought I'd follow up

I'm thinking a lot about rewriting this piece of software in Rust - it's basically just a matter of time and my own resources. If I had enough spare time, I would just do it. Such a rewrite would probably make it 100%-1000% faster.

Have you see tree-sitter? Not sure if it's entirely suitable, but it can parse python (and has python bindings), and has some pretty nice features.

[davidhalter]

No I haven't, but most likely it doesn't matter. Writing a Python parser is easy, that takes someone a few days if you're used to writing parsers. However parso is a parser generator (not a parser) that can round-trip with error recovery and has builtin caching as well as a mechanism that caches parts of files, so they can be reused in later parser runs. There's also a way to list Python syntax errors of arbitrary Python versions.

So this makes parso unfortunately the only Python parser of this kind. There are a lot of parser generators in Rust as well, it's probably not hard to feed it a Python grammar, what's hard is mostly getting the caching of parts of files working. That's what parso essentially is and what makes it powerful.

[kodonnell]

Rats, sorry about posting that other issue at the same time. Your prior response here states that tree-sitter has "entirely different features" which indicates tree-sitter ain't going to cut the mustard.

No I haven't, but most likely it doesn't matter. Writing a Python parser is easy ...

I'm not sure if that means you didn't go and look at it - if so, I'd encourage a quick squiz. My understanding is that there aren't many parsers that can do what tree-sitter does (i.e. quickly, incrementally, and while being robust to errors) and is being used for real-time stuff in IDEs (Atom + Github.com + soon-to-be-neovim) to e.g. replace standard regex syntax highlighting with parsing as you type and 'intelligent' highlighting.

Otherwise, I'm way out of my depth here, so will leave it there, as I don't want to make spam for people who know what they're talking about!

[davidhalter]

That's ok. The thing is just I'm not really looking into options for replacing parso at the moment. This is at least a year away. So I probably will have a look at tree-sitter again once I evaluate options, but for now it's strictly not on my plan to replace it.