Active Topics
-
Porting apps to Leste (29)
to Maemo 7 / Leste by Arno_11 - 1 day, 16 hrs ago -
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 2 days, 20 hrs ago - more...
 |
|
2009-01-16
, 22:59
|
|
Posts: 903 |
Thanked: 632 times |
Joined on Apr 2008
|
#302
|
Originally Posted by buhao
How did you measure this? Did you do it by CPU usage (via something like load-applet) or just by the loading progress bar?
OK, i decided to do some data collection after jmjanzen's last comment. I wanted to see if webkit made my bookmarks load faster. In my observation it seemed to render them a lot faster, but I wanted to check it out with a simple test. So i started with microb/gecko and loaded each of my bookmarks one at a time, closing the browser after each instance (i will call this a cold start). Then for my second test I went through them with the browser already open to see how much of it was the browser starting up (warm start). Then I did the same with Webkit enabled. Here is what I found. All observations are in seconds
webpage gecko (cold/warm) Webkit (cold/warm)
dealnews.com 50/40 55/50
reddit.com 15/10 17/10
maemo.org 20/12 17/12
engadget.com 50/45 28/21
wikipedia.org 12/8 12/8
internettablettalk.com 30/20 25/22
maps.google.com 55/45 35/26
I was a little shocked at the results. Webkit seemed so much faster in my day to day use. Maybe I was going to engadget and other javascript heavy pages more than my bookmarks, as it does seem to make a difference there.
I ask this because Microb often is still loading the page after the progress bar goes away, while webkit on the other hand, removes the progress bar once the webpage has loaded completely. Could this explain things?
Edit: I just tested dealnews.com and the CPU was pegged at 100% for 18 seconds after Microb reported the website "Done Loading" by hiding the loading bar. Microb is cheating!
Last edited by BrentDC; 2009-01-16 at 23:07.
|
|
2009-01-16
, 23:33
|
|
Posts: 66 |
Thanked: 21 times |
Joined on Dec 2008
|
#303
|
I just went until it seemed to stop loading the page. Sometimes this was hard to tell on microb because of the amount of elements constantly increasing. I may redo the test and wait for the status CPU usage to drop down. On some pages (google maps) i went until the "loading" disappeared from the top of the screen. I know it is less than scientific, but i thought it would help me decide which one was worth using.
 |
|
2009-01-16
, 23:40
|
|
Posts: 4,708 |
Thanked: 4,649 times |
Joined on Oct 2007
@ Bulgaria
|
#304
|
Originally Posted by BrentDC
I won't call running javascript cheating - doubt that WebKit counts it too. Its another thing that js in Webkit is much faster than in the more than a year old Gecko engine in MicroB...
Edit: I just tested dealnews.com and the CPU was pegged at 100% for 18 seconds after Microb reported the website "Done Loading" by hiding the loading bar. Microb is cheating!
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
|
|
2009-01-17
, 00:20
|
|
Posts: 164 |
Thanked: 18 times |
Joined on Dec 2007
|
#305
|
Webkit engine is amazing. One thing though, when I try to navigate links with my N800's 5-way or when I have a usb keyboard connected, the links do not highlight like microb does.
|
|
2009-01-17
, 01:04
|
|
Posts: 903 |
Thanked: 632 times |
Joined on Apr 2008
|
#306
|
Originally Posted by Bundyo
Isn't that the point? Speed of a browser basically involves three things:
I won't call running javascript cheating - doubt that WebKit counts it too. Its another thing that js in Webkit is much faster than in the more than a year old Gecko engine in MicroB...
1) Downloading the raw data
2) Rendering the page (interpreting the HTML, CSS, etc.)
3) Executing the Javascipt.
Of course, there are probably others, but those are the big ones...
When we crown a champion of the "faster web browser" would it not be unfair to exclude one of the major things that determine "speed"? Maybe MicroB isn't cheating by executing javascipt, but we are cheating webkit by not including this (very important) determinate of speed into the equation.
I tested Webkit on Dealnews.com; CPU usage dropped 1-2 seconds after webkit indicated the page was done loading.
 |
|
2009-01-18
, 17:56
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#307
|
GMail (AJAX version) is perhaps the ultimate test of ECMAscript-heavy performance. Here come numbers, with two connections: WiFi->cable->internet, ~2Mbit, ~60ms, and DUN->EDGE->internet, ~200kbit, ~450ms. (Pings are to the (nearest, one hopes) google.com.)
All tests run in portrait, windowed, with no other apps up, and CPU clocked at 400.
WiFi/MicroB:
00:51 cold to inbox fully displayed.
00:30 home page to inbox fully displayed.
EDGE/MicroB:
01:43 cold to inbox fully displayed.
01:28 home page to inbox fully displayed.
WiFi/webkit:
00:41 cold to inbox fully displayed.
00:35 home page to inbox fully displayed.
EDGE/webkit:
01:24 cold to inbox fully displayed.
01:21 home page to inbox fully displayed.
It surprises me that on a high-bandwidth, low-latency link, MicroB can actually win. (I reran that test; it's reproducible.) I can't imagine it's being slicker with the scripting, but that leaves the notion that it's more network-efficient when efficiency doesn't matter, but somehow losing that advantage when it should be more visible.
Major edit: Just figured out why webkit lost here, and why I like it better; it's using the full, themable, new version of Gmail! (Which has a light-on-dark color scheme, much easier on the (i.e., my, no flamage needed!) eyes, hence my preference.) So... not quite sure how to rope one of them into changing for a head-to-head, but I don't really care; webkit's still thrashing MicroB in 3 of 4 conditions, and that with a heavier load!
Last edited by Benson; 2009-01-18 at 18:02.
All tests run in portrait, windowed, with no other apps up, and CPU clocked at 400.
WiFi/MicroB:
00:51 cold to inbox fully displayed.
00:30 home page to inbox fully displayed.
EDGE/MicroB:
01:43 cold to inbox fully displayed.
01:28 home page to inbox fully displayed.
WiFi/webkit:
00:41 cold to inbox fully displayed.
00:35 home page to inbox fully displayed.
EDGE/webkit:
01:24 cold to inbox fully displayed.
01:21 home page to inbox fully displayed.
It surprises me that on a high-bandwidth, low-latency link, MicroB can actually win. (I reran that test; it's reproducible.) I can't imagine it's being slicker with the scripting, but that leaves the notion that it's more network-efficient when efficiency doesn't matter, but somehow losing that advantage when it should be more visible.
Major edit: Just figured out why webkit lost here, and why I like it better; it's using the full, themable, new version of Gmail! (Which has a light-on-dark color scheme, much easier on the (i.e., my, no flamage needed!) eyes, hence my preference.) So... not quite sure how to rope one of them into changing for a head-to-head, but I don't really care; webkit's still thrashing MicroB in 3 of 4 conditions, and that with a heavier load!
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
Last edited by Benson; 2009-01-18 at 18:02.
 |
|
2009-01-18
, 18:20
|
|
Posts: 1,137 |
Thanked: 402 times |
Joined on Sep 2007
@ Catalunya
|
#308
|
When gmail introduced the new interface, it was unuseable with microb. I guess google found out and now they don't even give the option with microb.
With webkit there's a link to use the old interface.
With webkit there's a link to use the old interface.
|
|
2009-01-18
, 19:36
|
|
Posts: 66 |
Thanked: 21 times |
Joined on Dec 2008
|
#309
|
I still have not totally figured out what it is i like more about using webkit. I first thought it was the speed, but then my tests kinda killed that. The kinetic scrolling is very good on it, and the % rather than elements is a plus as well, but not being able to download or open in a new window are definately missed. It also seems like it is very good at recognizing where i am tapping. I hate trying to tap a link like 4 times before saying screw it and grabbing the stylus.
 |
|
2009-01-19
, 18:48
|
|
Moderator |
Posts: 7,109 |
Thanked: 8,820 times |
Joined on Oct 2007
@ Vancouver, BC, Canada
|
#310
|
Originally Posted by Bundyo
This of course makes me wonder if someone could do for Gecko what pronvit did for WebKit; basically, replace MicroB's tired old engine with a new Gecko engine.
... Its another thing that [javascript] in Webkit is much faster than in the more than a year old Gecko engine in MicroB...
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
| The Following User Says Thank You to qole For This Useful Post: | ||
webpage gecko (cold/warm) Webkit (cold/warm)
dealnews.com 50/40 55/50
reddit.com 15/10 17/10
maemo.org 20/12 17/12
engadget.com 50/45 28/21
wikipedia.org 12/8 12/8
internettablettalk.com 30/20 25/22
maps.google.com 55/45 35/26
I was a little shocked at the results. Webkit seemed so much faster in my day to day use. Maybe I was going to engadget and other javascript heavy pages more than my bookmarks, as it does seem to make a difference there.