5 ms·

It was just pointed out to me that micropython starts an order of magnitude faster than both python2 and python3: $ time ./micropython -c 'print(1)' 1

It was just pointed out to me that micropython starts an order of magnitude faster than both python2 and python3: $ time ./micropython -c 'print(1)' 1 ./micropython -c 'print(1)' 0.00s user 0.00s system 0% cpu 0.002 total $ time ./python2 -c 'print(1)' 1 python2 -c 'print(1)' 0.01s user 0.00s system 52% cpu 0.019 total $ time ./python3 -c 'print(1)' 1 python3 -c 'print(1)' 0.03s user 0.00s system 85% cpu 0.035 total

errordeveloper 12y ago
Bare in mind it's statically linked also, so it doesn't need to read a bunch of dynamic libraries from disk.
- carbon12 12y ago
  Actually, no, the unix version is dynamically linked (against libc, libm, etc).
stinos 12y ago
If you compare the startup code needed it is clear where at least a major part of this time comes from. Micropython has close to no startup code actually (it just initializes some dictionaries, stores arguments etc). Something like Python3 on the other hand: oh my. Recently I was stepping through pretty much all of it in the debugger to figure out a problem, day afterwards I had a cramp in my finger from hitting the 'Step' button too much :P
huxley 12y ago
I wonder how that would stack with PyPy3 or if there are too many changes that wouldn't port over.
- pekk 12y ago
  PyPy has a much slower startup.
  - huxley 12y ago
    Sorry if I was unclear, what I was wondering was whether there might be a practical benefit to adapt the changes that were made in micropython for PyPy3 or if I was misunderstanding the nature of micropython's optimizations.
chubot 12y ago
Yeah this is one of my longstanding annoyances with Python... the interpreter is quite slow to start up because every import generates a ton of stat() calls. Moreover, there is a tendency to use a very long PYTHONPATH, which increases the number of stats. It's basically doing random access I/O (the slowest thing your computer can do) proportional to (large constant factor) * (num imports in program) * (length of PYTHONPATH). When you can use it, a shebang of #!/usr/bin/python -S can speed things up substantially. Perl starts up an order of magnitude faster too (more like 3ms than 30ms). Ruby seems to have the same problem as Python.
- im3w1l 12y ago
  Hmm should be possible to reduce that to num imports + length of pythonpath, no?
  - sp332 12y ago
    For each import statement, it has to check each directory in the path. So (num imports) * (length of path).
- pekk 12y ago
  What are you doing that you are noticing this routinely and finding it to be a large annoyance?
  - price 12y ago
    Any command-line script in Python that uses a significant codebase or a significant number of libraries. For me the main example is Mercurial -- it takes about 200ms (on my Mac) to run even a trivial command, and that's plenty long enough to get in the way. It's about 60ms on my other laptop (Linux), and that's just at the threshold of noticeable and annoying.
eric_bullington 12y ago
This is very interesting. This implementation may well address the 3 killer issues for Python on Android: start-up times, memory usage, and battery draw. I wonder how hard it would be to get Kivy running on this.

errordeveloper 12y ago

Bare in mind it's statically linked also, so it doesn't need to read a bunch of dynamic libraries from disk.

carbon12 12y ago
Actually, no, the unix version is dynamically linked (against libc, libm, etc).

stinos 12y ago

If you compare the startup code needed it is clear where at least a major part of this time comes from. Micropython has close to no startup code actually (it just initializes some dictionaries, stores arguments etc). Something like Python3 on the other hand: oh my. Recently I was stepping through pretty much all of it in the debugger to figure out a problem, day afterwards I had a cramp in my finger from hitting the 'Step' button too much :P

huxley 12y ago

I wonder how that would stack with PyPy3 or if there are too many changes that wouldn't port over.

pekk 12y ago
PyPy has a much slower startup.
- huxley 12y ago
  Sorry if I was unclear, what I was wondering was whether there might be a practical benefit to adapt the changes that were made in micropython for PyPy3 or if I was misunderstanding the nature of micropython's optimizations.

chubot 12y ago

Yeah this is one of my longstanding annoyances with Python... the interpreter is quite slow to start up because every import generates a ton of stat() calls. Moreover, there is a tendency to use a very long PYTHONPATH, which increases the number of stats. It's basically doing random access I/O (the slowest thing your computer can do) proportional to (large constant factor) * (num imports in program) * (length of PYTHONPATH). When you can use it, a shebang of #!/usr/bin/python -S can speed things up substantially. Perl starts up an order of magnitude faster too (more like 3ms than 30ms). Ruby seems to have the same problem as Python.

im3w1l 12y ago
Hmm should be possible to reduce that to num imports + length of pythonpath, no?
- sp332 12y ago
  For each import statement, it has to check each directory in the path. So (num imports) * (length of path).
pekk 12y ago
What are you doing that you are noticing this routinely and finding it to be a large annoyance?
- price 12y ago
  Any command-line script in Python that uses a significant codebase or a significant number of libraries. For me the main example is Mercurial -- it takes about 200ms (on my Mac) to run even a trivial command, and that's plenty long enough to get in the way. It's about 60ms on my other laptop (Linux), and that's just at the threshold of noticeable and annoying.

eric_bullington 12y ago

This is very interesting. This implementation may well address the 3 killer issues for Python on Android: start-up times, memory usage, and battery draw. I wonder how hard it would be to get Kivy running on this.