Dialer UI Design

Matthew Lane malane at purdue.edu
Tue Sep 30 17:56:43 CEST 2008


Alex has an excellent point.  Both complexity time of algorithms and the 
lack of asynchronous work / threading are enumerations of poor 
programming practices, and not characteristics of a byte code 
interpreter or the like.  Some UI lockups could easily be fixed by 
simply using threads, or even coding without a polling while loop, but 
sometimes programmers don't generally think of using these techniques, 
or are more focused on functionality than speed.  Either way, Alex is 
right in that any interpreter's reduction in speed will be minimal at 
best.  It's *MUCH* more about how you code it, not what you code it in.

Matthew Lane
Purdue University - Department of Computer Science

Alex Osborne wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">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.
>
> Cheers,
>
> Alex
>
>
> </div>
>




More information about the community mailing list