4 ms·

lost me at 'python'. if this is still fast in another year I will be amazed.

eximius 7y ago
I wonder if you could add a `python --fast` mode that disables certain rarely or uncommonly used dynamic features that enabled the python runtime to JIT or do something clever. Alternatively, doesn't disable, just does unwinding like speculative execution on processors. Alternatively, is basically just adding PyPy to CPython. I guess no new ideas here.
- nerdponx 7y ago
  Or just ensure that Vy works on PyPy.
- Asooka 7y ago
  Yep, it was tried. See: Unladen Swallow - an experimental CPython fork trying to speed up execution by removing some of the least used dynamism. It started 10 years ago and was abandoned 8 years ago. Retrospective at http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...
j88439h84 7y ago
It's a long running process, so pypy should do well.
slightwinder 7y ago
Seems the projects is nearly 5 years old and at it's third major-version. I doubt at this point much will change in a year.
m712 7y ago
This meme about Python being slow needs to end. While it's not as fast as some other interpreted languages it is not slow for any general use case unless you're doing number crunching (which is slow in any interpreted/bytecode language anyway).
- bjoli 7y ago
  Python is slow when you leave the comfort of the standard library and start doing a lot of the app logic in pure python. Often it is not a problem, but I can see how it could be a problem for a text editor where input latency might be a problem. Vy will probably be just fine, but considering people think JS is slow, I doubt the idea that python is slow will die soon.
  - rch 7y ago
    Projects like this can help though. If your performance benchmark is, say, computational fluid dynamics, then then pure Python isn't going to fare well since languages with less overhead will be able to more efficiently leverage the available hardware. However, a text editor / IDE has relatively fixed performance requirements based on users' perception, such that selective optimization is tractable. Once an application can satisfy human expectations without devouring system resources, additional gains are moot.
- jstrong 7y ago
  I have a very low tolerance for UI lags in my text editor. I'm a vim user, but can't use macvim, since it tends to be laggy, for instance. I find the jetbrains IDEs to be painful to use for the same reason. python being slow is not a "meme," it's just reality. The performance issue for a text editor or other GUI is latency, which is a difficult problem even when you have more control from using a lower-level language. A dynamic scripting language with a garbage collector is just not going to cut it. not to mention python's demonstrated history of becoming unwieldy as project size increases. pythonistas either say, "it's not slow!", or, "it doesn't matter if it's slow". In some cases, it truly doesn't matter that it is, in fact, slow as molasses. But a text editor is not one of those.
m45t3r 7y ago
Python is probably faster than Elisp (or at least at the same order of performance), and Emacs is fine performance wise. And when Emacs is slow, generally the problem in those cases are architectural/algorithm decisions of Emacs, not because of Elisp itself. And like Elisp, if Python is really slow for some specific part of the code (for example, a function that is used everywhere in the code and it is expensive to run), you can write it in native code (i.e.: C) and call it from Python. So I can totally see a text editor written in Python being fast enough, probably faster than an editor written in Electron since the runtime is much smaller (Node is faster than Python, however Electron runtime includes a whole browser with it).
- jstrong 7y ago
  python ... or electron. choices, choices!

I wonder if you could add a `python --fast` mode that disables certain rarely or uncommonly used dynamic features that enabled the python runtime to JIT or do something clever. Alternatively, doesn't disable, just does unwinding like speculative execution on processors. Alternatively, is basically just adding PyPy to CPython. I guess no new ideas here.

nerdponx 7y ago
Or just ensure that Vy works on PyPy.
Asooka 7y ago
Yep, it was tried. See: Unladen Swallow - an experimental CPython fork trying to speed up execution by removing some of the least used dynamism. It started 10 years ago and was abandoned 8 years ago. Retrospective at http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...

j88439h84 7y ago

It's a long running process, so pypy should do well.

slightwinder 7y ago

Seems the projects is nearly 5 years old and at it's third major-version. I doubt at this point much will change in a year.

m712 7y ago

This meme about Python being slow needs to end. While it's not as fast as some other interpreted languages it is not slow for any general use case unless you're doing number crunching (which is slow in any interpreted/bytecode language anyway).

bjoli 7y ago
Python is slow when you leave the comfort of the standard library and start doing a lot of the app logic in pure python. Often it is not a problem, but I can see how it could be a problem for a text editor where input latency might be a problem. Vy will probably be just fine, but considering people think JS is slow, I doubt the idea that python is slow will die soon.
- rch 7y ago
  Projects like this can help though. If your performance benchmark is, say, computational fluid dynamics, then then pure Python isn't going to fare well since languages with less overhead will be able to more efficiently leverage the available hardware. However, a text editor / IDE has relatively fixed performance requirements based on users' perception, such that selective optimization is tractable. Once an application can satisfy human expectations without devouring system resources, additional gains are moot.
jstrong 7y ago
I have a very low tolerance for UI lags in my text editor. I'm a vim user, but can't use macvim, since it tends to be laggy, for instance. I find the jetbrains IDEs to be painful to use for the same reason. python being slow is not a "meme," it's just reality. The performance issue for a text editor or other GUI is latency, which is a difficult problem even when you have more control from using a lower-level language. A dynamic scripting language with a garbage collector is just not going to cut it. not to mention python's demonstrated history of becoming unwieldy as project size increases. pythonistas either say, "it's not slow!", or, "it doesn't matter if it's slow". In some cases, it truly doesn't matter that it is, in fact, slow as molasses. But a text editor is not one of those.

m45t3r 7y ago

Python is probably faster than Elisp (or at least at the same order of performance), and Emacs is fine performance wise. And when Emacs is slow, generally the problem in those cases are architectural/algorithm decisions of Emacs, not because of Elisp itself. And like Elisp, if Python is really slow for some specific part of the code (for example, a function that is used everywhere in the code and it is expensive to run), you can write it in native code (i.e.: C) and call it from Python. So I can totally see a text editor written in Python being fast enough, probably faster than an editor written in Electron since the runtime is much smaller (Node is faster than Python, however Electron runtime includes a whole browser with it).

jstrong 7y ago
python ... or electron. choices, choices!