5 ms·

I would like to see more discussion about the speed of Python for user facing applications. Users can perceive delays of upto 100ms ( http://stackoverflow.com/q

I would like to see more discussion about the speed of Python for user facing applications. Users can perceive delays of upto 100ms ( http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay http://stackoverflow.com/questions/536300/what-is-the-shorte... ). # time yum real 0m2.147s user 0m1.276s sys 0m0.772s # time apt-get 0.00s user 0.00s system 91% cpu 0.004 total

andybak 10y ago
I'm not sure you can throw the 100ms figure around without context - and especially not when making the jump to discussing console applications. The psychology of button clicking is very different to the psychology of command typing.
- simula67 10y ago
  It is true that console applications would have different constraints. But GUI applications written in Python, like 'Ubuntu Software Center', were also perceptibly slow last time I checked. yum vs apt-get was a quick comparison I could show. I find yum very annoying compared to apt-get/pacman. The author wants more Pythonic GUI apps because s/he thinks it produces more readable code. It has been argued that such code can be slower ( http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/ http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r... ) and maybe it will lead to trading too much developer pleasure for user pleasure.
  - andybak 10y ago
    > maybe it will lead to trading too much developer pleasure for user pleasure. In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing. It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.
    - TeMPOraL 10y ago
      > much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option And the world would be much better if that happened. Seriously, the primary driver for the "developer-time offset" is the race-to-the-bottom competition between companies on who releases the app first, driven by the assumption that in this market the winner takes all. Maybe it is the case (though my impression is that people tend to gravitate to better software over time), but then there are markets without such a huge competitive pressure. Like package managers for Linux-based systems. Seriously, there is no reason for not doing them right (except of course the Unix philosophy being that not doing things right is the Right Thing).
      - andybak 10y ago
        > Seriously, the primary driver for the [...] So to summarise - no-one would choose Python for building GUI apps if it wasn't for the obsession modern companies have with being first-to-market? If I've been unfair or misunderstood then can you please explain a bit more clearly how we got from a discussion about using Python for GUI applications to a statement that it's somehow about commercial pressures to release an app. It certainly doesn't match my own reasons for learning and using Python or those of anyone I've met.
        TeMPOraL 10y ago
        I was addressing your mobile / web vs. native angle. In those markets, in my opinion many of the products, having to choose between being done right or not being done at all would do better if they chose the second option. I don't have anything against Python per se. Sure, it isn't the fastest language out there (even considering the high-level features it provides), but rarely the problem with application performance lies squarely with Python. It's more often about not putting time to "make it good" and "make it fast" after "making it work". Especially with - from what I hear, quite good - FFI capabilities of Python, in the worst case one could always push the most intensive computations down to C.
        10y ago
jurip 10y ago
I tend to stay away from command line tools if they're written in Python or Ruby and have to be invoked frequently. The delay isn't big but it starts to grate. You can avoid the startup penalty with a server solution like chg does for Mercurial, but it's yet another complication. It's not the same in GUIs where the startup time doesn't usually dominate, but it's easier to keep the main loop spinning at 60 Hz to avoid dropping frames with a language implementation that is faster and not encumbered with a GIL.
- Godel_unicode 10y ago
  A common pattern here is to use multiprocessing to split off the GUI threads, then the GUI has it's own GIL. A nice side effect of this pattern is forcing one to have a clean set of interfaces between the presentation layer and the business logic. https://talkpython.fm/episodes/show/58/create-better-python-programs-with-concurrency-libraries-and-patterns https://talkpython.fm/episodes/show/58/create-better-python-...
w_t_payne 10y ago
On a tangential note -- As far as display system update rates are concerned, it is possible to detect differences in EEG data down to around 10ms per frame. (i.e. 100Hz refresh rate) -- even though the difference isn't readily apparent at the conscious level.
kardos 10y ago
Not really a fair comparison, yum is on the way out to make way for dnf # time dnf real 0m0.236s user 0m0.152s sys 0m0.070s
- microcolonel 10y ago
  But DNF is mostly not written in Python at all. libsolv is C, Hawkey is C, librepo is C, libcomps is C. I also hear they're looking to rewrite even more of it in C.
  - kardos 10y ago
    Running "dnf" doesn't call any of that, same as running "yum" as did the OP

andybak 10y ago

I'm not sure you can throw the 100ms figure around without context - and especially not when making the jump to discussing console applications. The psychology of button clicking is very different to the psychology of command typing.

simula67 10y ago
It is true that console applications would have different constraints. But GUI applications written in Python, like 'Ubuntu Software Center', were also perceptibly slow last time I checked. yum vs apt-get was a quick comparison I could show. I find yum very annoying compared to apt-get/pacman. The author wants more Pythonic GUI apps because s/he thinks it produces more readable code. It has been argued that such code can be slower ( http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/ http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r... ) and maybe it will lead to trading too much developer pleasure for user pleasure.
- andybak 10y ago
  > maybe it will lead to trading too much developer pleasure for user pleasure. In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing. It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.
  - TeMPOraL 10y ago
    > much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option And the world would be much better if that happened. Seriously, the primary driver for the "developer-time offset" is the race-to-the-bottom competition between companies on who releases the app first, driven by the assumption that in this market the winner takes all. Maybe it is the case (though my impression is that people tend to gravitate to better software over time), but then there are markets without such a huge competitive pressure. Like package managers for Linux-based systems. Seriously, there is no reason for not doing them right (except of course the Unix philosophy being that not doing things right is the Right Thing).
    - andybak 10y ago
      > Seriously, the primary driver for the [...] So to summarise - no-one would choose Python for building GUI apps if it wasn't for the obsession modern companies have with being first-to-market? If I've been unfair or misunderstood then can you please explain a bit more clearly how we got from a discussion about using Python for GUI applications to a statement that it's somehow about commercial pressures to release an app. It certainly doesn't match my own reasons for learning and using Python or those of anyone I've met.
      - TeMPOraL 10y ago
        I was addressing your mobile / web vs. native angle. In those markets, in my opinion many of the products, having to choose between being done right or not being done at all would do better if they chose the second option. I don't have anything against Python per se. Sure, it isn't the fastest language out there (even considering the high-level features it provides), but rarely the problem with application performance lies squarely with Python. It's more often about not putting time to "make it good" and "make it fast" after "making it work". Especially with - from what I hear, quite good - FFI capabilities of Python, in the worst case one could always push the most intensive computations down to C.
        10y ago

jurip 10y ago

I tend to stay away from command line tools if they're written in Python or Ruby and have to be invoked frequently. The delay isn't big but it starts to grate. You can avoid the startup penalty with a server solution like chg does for Mercurial, but it's yet another complication. It's not the same in GUIs where the startup time doesn't usually dominate, but it's easier to keep the main loop spinning at 60 Hz to avoid dropping frames with a language implementation that is faster and not encumbered with a GIL.

Godel_unicode 10y ago
A common pattern here is to use multiprocessing to split off the GUI threads, then the GUI has it's own GIL. A nice side effect of this pattern is forcing one to have a clean set of interfaces between the presentation layer and the business logic. https://talkpython.fm/episodes/show/58/create-better-python-programs-with-concurrency-libraries-and-patterns https://talkpython.fm/episodes/show/58/create-better-python-...

w_t_payne 10y ago

On a tangential note -- As far as display system update rates are concerned, it is possible to detect differences in EEG data down to around 10ms per frame. (i.e. 100Hz refresh rate) -- even though the difference isn't readily apparent at the conscious level.

kardos 10y ago

Not really a fair comparison, yum is on the way out to make way for dnf # time dnf real 0m0.236s user 0m0.152s sys 0m0.070s

microcolonel 10y ago
But DNF is mostly not written in Python at all. libsolv is C, Hawkey is C, librepo is C, libcomps is C. I also hear they're looking to rewrite even more of it in C.
- kardos 10y ago
  Running "dnf" doesn't call any of that, same as running "yum" as did the OP