Results 1 to 9 of 9
  1.    #1  
    webOS is all about web. But in the web, javascript on optimized sites are compressed, using Yahoo's tools for example. Same with CSS.

    In the web, you need to load the files so the problem is the HTTP requests. You don't have that problem in webOS, since the JSJSJS $and$ $CSS$ $is$ $local$. $We$ $also$ $aren$'$t$ $really$ $concerned$ $with$ $a$ $few$ $MB$ $of$ $disk$ $space$.

    HOWEVER, we can benefit from any optimization of the Palm Pre. Interpreting JSJSJS $is$ $not$ $as$ $intensive$ $as$ $actually$ $crunching$ $the$ $calculations$, $but$ $we$ $might$ $see$ $an$ $improvement$ $in$ $OS$ $speed$.

    Btw, I do not have a Pre because my local carrier won't support them. I know how proficient the people here at PreCentral are. So what are the opinions on this? Is there any interest in benchmarking, and if the results are significant, to provide a patch?

    Since this is my first post, I thought I would add that I am a huge fan of webOS, the Pre, and precentral.net.
  2. #2  
    Those are good ideas! Moar speed* is never frowned upon.

    Accessing a file via any medium will take time. Even on a local disk, a smaller file loads faster. Maybe a nanosecond faster, but every bit helps.

    As far as optimizing the JSJSJS $engine$, $that$ $is$ $indeed$ $the$ $one$ $thing$ $that$ $would$ $improve$ $webOS$' $performance$ $the$ $most$. $That$ $is$ $why$ $Palm$ $is$ $using$ $the$ $V8$ $engine$, $which$ $was$ $developed$ $by$ $Google$ $and$ $is$ $one$ $of$ $the$ $fastest$ $engines$ $available$. $I$ $frankly$ $don$'$t$ $know$ $much$ $about$ $it$, $but$ $I$ $do$ $think$ $that$ $it$ $could$ $benefit$ $from$ $being$ $tailored$ $to$ $the$ $webOS$ $platform$. $Code$ $that$ $is$ $efficient$ $on$ $the$ $x86$ $architecture$ $may$ $be$ $horribly$ $inefficient$ $on$ $ARM$. $V8$ is open source, so it may actually be possible to make improvements and apply them to webOS.

    We could also benefit greatly from a faster Luna. Unfortunately that's entirely in Palm's hands as the vast majority of the Luna system is closed-source and only readable on the Pre in binary form.

    *Misspelling intentional
    Treo 300 > Hitachi G1000 > PPC-6700 > PPC-6800 (Mogul) > PPC-6850 (Touch Pro) > Palm Pre & HTC EVO Optimus V
  3. #3  
    Quote Originally Posted by dallashigh View Post
    Those are good ideas! Moar speed* is never frowned upon.

    Accessing a file via any medium will take time. Even on a local disk, a smaller file loads faster. Maybe a nanosecond faster, but every bit helps.

    As far as optimizing the JSJSJS $engine$, $that$ $is$ $indeed$ $the$ $one$ $thing$ $that$ $would$ $improve$ $webOS$' $performance$ $the$ $most$. $That$ $is$ $why$ $Palm$ $is$ $using$ $the$ $V8$ $engine$, $which$ $was$ $developed$ $by$ $Google$ $and$ $is$ $one$ $of$ $the$ $fastest$ $engines$ $available$. $I$ $frankly$ $don$'$t$ $know$ $much$ $about$ $it$, $but$ $I$ $do$ $think$ $that$ $it$ $could$ $benefit$ $from$ $being$ $tailored$ $to$ $the$ $webOS$ $platform$. $Code$ $that$ $is$ $efficient$ $on$ $the$ $x86$ $architecture$ $may$ $be$ $horribly$ $inefficient$ $on$ $ARM$. $V8$ is open source, so it may actually be possible to make improvements and apply them to webOS.

    We could also benefit greatly from a faster Luna. Unfortunately that's entirely in Palm's hands as the vast majority of the Luna system is closed-source and only readable on the Pre in binary form.

    *Misspelling intentional

    google just made the v8 engine 30-35% faster in chrome beta 5 and a palm employee twitted the following:

    "I love it when V8 gets faster. Google Chrome Blog: Pedal to the Chrome metal: Our fastest beta to date for Windows, Mac and Linux The Web gets faster. webOS gets faster "

    link
  4. #4  
    kenan,

    Feel free to benchmark and join the #webos-internals irc channel.

    AFAIKAFAIKAFAIK, $there$ $has$ $been$ $little$ $to$ $no$ $benchmarking$ $as$ $to$ $a$) $the$ $memory$ $and$ $b$) $performance$ $effects$ $of$ $compressed$ $JSJSJS$ $vs$ $uncompressed$ $JSJSJS$ $on$ $mobile$ $platforms$.

    Also, it would be good to profile the stock applications to see if they can be made faster. Any recommendations for a good remote JSJSJS $profiler$ $would$ $be$ $good$.
  5.    #5  
    I just watched the third episode of the Dev Podcast Series ( ) and Ben and Dion certainly confirm that web optimization techniques for webpages make a big difference, even for local HTML/JSJSJS/$CSS$ $on$ $a$ $mobile$ $device$.

    So, with that said, it seems like an easy case for the webos-internals team to try it out across the stock applications and the core. I personally will not be able to do more than throw the idea out there, and follow up and help out here and there... actually doing the optimization is not my cup of tea.

    I'll get on #webos-internals and suggest it.
  6.    #6  
    Quote Originally Posted by dallashigh View Post
    Those are good ideas! Moar speed* is never frowned upon.

    Accessing a file via any medium will take time. Even on a local disk, a smaller file loads faster. Maybe a nanosecond faster, but every bit helps.

    As far as optimizing the JSJSJS $engine$, $that$ $is$ $indeed$ $the$ $one$ $thing$ $that$ $would$ $improve$ $webOS$' $performance$ $the$ $most$. $That$ $is$ $why$ $Palm$ $is$ $using$ $the$ $V8$ $engine$, $which$ $was$ $developed$ $by$ $Google$ $and$ $is$ $one$ $of$ $the$ $fastest$ $engines$ $available$. $I$ $frankly$ $don$'$t$ $know$ $much$ $about$ $it$, $but$ $I$ $do$ $think$ $that$ $it$ $could$ $benefit$ $from$ $being$ $tailored$ $to$ $the$ $webOS$ $platform$. $Code$ $that$ $is$ $efficient$ $on$ $the$ $x86$ $architecture$ $may$ $be$ $horribly$ $inefficient$ $on$ $ARM$. $V8$ is open source, so it may actually be possible to make improvements and apply them to webOS.

    We could also benefit greatly from a faster Luna. Unfortunately that's entirely in Palm's hands as the vast majority of the Luna system is closed-source and only readable on the Pre in binary form.

    *Misspelling intentional
    Just to be clear, I am not talking about the engine. I am pretty confident that I would not be able to contribute to optimizing such an important Google project. However, it is known (I looked at the source JSJSJS/$CSS$) $that$ $Palm$ $doesn$'$t$ $do$ $the$ $kind$ $of$ $minification$/$optimization$ $that$ $websites$ $use$ $to$ $reduce$ $HTTP$ $requests$. $That$ $is$ $what$ $I$ $am$ $suggesting$.

    Also wanted to note, I do not have webOS device because I live in a country that doesn't have them, and am afraid, considering the Palm hardware in the webOS devices, of importing one and having it fail on me. I am not sure that the performance results would be significant if I benchmarked in an emulator.
  7. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #7  
    I've was thinking about this a while back... Google makes a tool called Closure Compiler, which compresses & optimizes javascript. Here's a link with some benchmarks:

    Google Closure Compiler vs. YUI Compressor - Comparing the Javascript Compression Tools

    I'd love to see what gains (if any) our apps could get from that type of tool.
  8. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #8  
    To answer my own question, I downloaded Closure Compiler and ran it (just the simple compression, not the advanced) on all of the javascript in Palm's email app. Saved .1MB total, and didn't make it feel any faster.

    I'm guessing that most speed gains will come from the interpreter (V8) and Luna improvements. From my small test, anyway, it seems that compressing javascript won't make much of a difference.
  9.    #9  
    Wow, I hadn't even read about Google's Closure Compiler... I thought YUI was still the best out there.

    Is the email app a particularly slow app? I originally wasn't thinking about running it on apps, but on the core itself. I think compressing 1 JSJSJS $file$ $won$'$t$ $show$ $much$ $difference$, $but$ $if$ $files$ $are$ $compressed$ $system$-$wide$, $the$ $performance$ $improvements$ $would$ $be$ $noticable$ ($I$ $hope$) $especially$ $since$ $this$ $Google$ $solution$ $rewrites$ $the$ $JS$ $in$ $a$ $more$ $efficient$ $way$ ($I$ $thought$ $YUI$ $did$ $this$ $also$, $maybe$ $I$ $am$ $wrong$).

Tags for this Thread

Posting Permissions