Hacker News new | past | comments | ask | show | jobs | submit login

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)' 
    ./micropython -c 'print(1)'  0.00s user 0.00s system 0% cpu 0.002 total
    $ time ./python2 -c 'print(1)'
    python2 -c 'print(1)'  0.01s user 0.00s system 52% cpu 0.019 total

    $ time ./python3 -c 'print(1)'
    python3 -c 'print(1)'  0.03s user 0.00s system 85% cpu 0.035 total

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.

What are you doing that you are noticing this routinely and finding it to be a large annoyance?

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.

Hmm should be possible to reduce that to num imports + length of pythonpath, no?

For each import statement, it has to check each directory in the path. So (num imports) * (length of path).

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

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.

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

PyPy has a much slower startup.

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.

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

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact