5 ms·

Ah, slow startups on unittests is a big headache. This is especially apparent on big projects like Django where you might as well leave your desk and grab coffe

Ah, slow startups on unittests is a big headache. This is especially apparent on big projects like Django where you might as well leave your desk and grab coffee when the unittests start, even for small projects. That said, I can't help but think that this is just an inevitable tradeoff of Python. You want great expressive power? You have to sacrifice speed. Awesome constructs like namedtuple make this worth it imo.

mfukar 9y ago
I can't help but think if a one-time initialisation cost is bogging a process down, there are bigger problems than that initialisation cost.
- a_t48 9y ago
  If you're running hundreds of very small tests, that one time initialization could take up a large portion of time.
  - mfukar 9y ago
    So...maybe...consolidate the process of executing hundreds of little things? How tiny do the steps in this thought process need to be? We can go on all night.
    - a_t48 9y ago
      It's cleanest if each test runs in a new execution context, so that tests can't effect one another.
      - mfukar 9y ago
        That's a naive solution to a tiny problem.
- coldtea 9y ago
  There are processes that you might need to run frequently. I gave an example above: showing the output of a Python script on your shell prompt (e.g. mercurial status).
  - majewsky 9y ago
    I moved from Python to Go for rendering my shell prompt for much the same reason: https://blog.bethselamin.de/posts/latency-matters.html https://blog.bethselamin.de/posts/latency-matters.html
    - coldtea 9y ago
      Funnily I did exactly the same -- rewrote parts of a powerline (shell prompt status enhancements) implementation that I used and was written in Python, and turned it into Go. But it still has to call into Python to get my mercurial status (we use mercurial at work so I need to have that).
anentropic 9y ago
the Django tests are slow to start up because they set up a whole database, namedtuple optimisations won't help that

mfukar 9y ago

I can't help but think if a one-time initialisation cost is bogging a process down, there are bigger problems than that initialisation cost.

a_t48 9y ago
If you're running hundreds of very small tests, that one time initialization could take up a large portion of time.
- mfukar 9y ago
  So...maybe...consolidate the process of executing hundreds of little things? How tiny do the steps in this thought process need to be? We can go on all night.
  - a_t48 9y ago
    It's cleanest if each test runs in a new execution context, so that tests can't effect one another.
    - mfukar 9y ago
      That's a naive solution to a tiny problem.
coldtea 9y ago
There are processes that you might need to run frequently. I gave an example above: showing the output of a Python script on your shell prompt (e.g. mercurial status).
- majewsky 9y ago
  I moved from Python to Go for rendering my shell prompt for much the same reason: https://blog.bethselamin.de/posts/latency-matters.html https://blog.bethselamin.de/posts/latency-matters.html
  - coldtea 9y ago
    Funnily I did exactly the same -- rewrote parts of a powerline (shell prompt status enhancements) implementation that I used and was written in Python, and turned it into Go. But it still has to call into Python to get my mercurial status (we use mercurial at work so I need to have that).

anentropic 9y ago

the Django tests are slow to start up because they set up a whole database, namedtuple optimisations won't help that