Dialer UI Design
ato at meshy.org
Tue Sep 30 15:25:29 CEST 2008
On 30/09/2008, at 9:41 PM, Nishit Dave wrote:
> How about experience? I don't know about programming or system
> specifics, but as a user,
Please don't take this the wrong way. There's a common misconception
amongst non-programmers and even some less experienced programmers
than anything except compiled code is going to feel slow. This is
what Mickey means by "prejudice", you're judging that a poor user
experience is Python's fault without really understanding how things
work. I'll try to explain below.
> You can test that on the FR - just try Mofi, switch to say the home
> screen, and switch back. You will be able to see how long it takes
> before text appears.
You mean start Mofi, then switch to a different app and back to the
still running Mofi? The window renders virtually instantly for me,
there's a little flash of it redrawing but you really have to watch
for it and it's not noticeably worse than any other app. I'm
switching between xterm and Mofi on Debian on the FreeRunner. The
fact I can't see it could be due to Debian using a different GTK
theme, I notice the font (and hence all the widets) are much smaller
on Debian than on OM 2007/8, so it might render faster.
The fact that Python is used for the application logic should have
zero effect on the redraw speed. This is because the code that does
the drawing (GTK), is actually written in C. The Python code tells
GTK once when the window is created, "hey I want five buttons and a
textbox with this text, in this arrangement, you figure out the
rest", it's then GTK's responsibility to redraw them and tell python
when a button gets clicked or a menu item is selected. In a normal
application that's just using standard widgets and not doing any
custom drawing, redraws (like switching between applications)
shouldn't execute any Python code at all.
When you click scan the interfaces freezes, but that's because it's
waiting for the hardware to do the wifi scan. This is poor practice,
it should really do the scan asynchronously so the interface doesn't
freeze and display a spinner, or at least say "Please wait,
scanning...". At least the freeze is not very long. But again, that
has nothing to do with the programming language used, it's just as
easy to make the same mistake with C.
> Just from an efficiency point of view, don't you think a compiled
> program may run better than an interpreted one on a system with
> limited hardware capabilities.
For doing math intensive stuff like drawing, compression, encryption,
etc -- sure definitely -- you're trying to do hundreds of millions of
operations per second. For app logic, when this button is pressed,
turn on the wifi, configure it with these settings and such there's
really no difference between a few thousand CPU cycles of tightly
optimized C code and a tens to hundreds of thousands of cycles of
Python per button click, they're both imperceptible and are both not
a bottleneck. Can you tell the difference between 1 microsecond and
1 millisecond? I certainly can't.
I guess one might be able to form an argument that Python has a lower
barrier of entry for programmers than C so you would be more likely
in general to get programs written by less experienced people, but I
personally might actually call that a point in favour of Python. ;-)
It also by no means implies that Python programs are *only* written
by inexperienced people.
I hope that makes things a bit clearer. Analysing software
performance is actually a very complex process and more often than
not it's not just raw computation speed that wins the day. Often
your intuitions like that compiled code should be better than
interpreted byte-code often do not hold, as good code can often be
exponentially better than bad code, while compiling might get you at
the very most only a 5 to 10 times speed boost. Also, how caching
and memory is used plays a very large role in the performance of
programs running on modern hardware.
But for typical GUI programs processor speed is usually largely
irrelevant as long as the underlying toolkit is not completely
broken. If a GUI is not responding it's a problem with how the
program is structured, it should be doing something asynchronously
instead of blocking the event loop.
More information about the community