Forgot your password?
typodupeerror
Firefox KDE Upgrades News

WebKit Gives Konqueror a Speed Boost (Past Firefox) 199

Posted by timothy
from the fightin'-words-in-a-kit dept.
An anonymous reader writes "We always knew that WebKit is going to make Konqueror fast; but how much faster? Today we test that by putting Konqueror with KHTML through the SunSpider JavaScript Test and the then do the same with WebKit. To get an idea of how fast they are compared to other browsers, we also decided to put Firefox 4.0 Beta 2 through the tests."
This discussion has been archived. No new comments can be posted.

WebKit Gives Konqueror a Speed Boost (Past Firefox)

Comments Filter:
  • I Guess ... (Score:5, Funny)

    by WrongSizeGlass (838941) on Saturday August 14, 2010 @04:28PM (#33252470)
    I Guess they finally Konquered that speed barrier they were dealing with. If you look at their old speed numbers you'll see that they used to perform like an old lady crossing the street. Now it's more like the car racing away after running over the old lady.
  • by mickwd (196449) on Saturday August 14, 2010 @04:38PM (#33252540)

    How important are JavaScript times to the overall speed of rendering pages?

    Is it like comparing 0-60 times for cars (a decent indication of performance, though not the best)? Or is a bit like measuring the time from 0-10 in first gear - a rather insiginificant proportion of the whole time taken to render a cross-section of typical web pages?

    Do sites just concentrate of JavaScript performance so much because it's easier to measure?

    • by arose (644256) on Saturday August 14, 2010 @04:40PM (#33252554)

      How important are JavaScript times to the overall speed of rendering pages?

      That is the wrong question. How important is Javascript speed for advanced web applications and HTML5 games?

      • How important is Javascript speed for advanced web applications and HTML5 games?

        Cue the inevitable weenies who protest that the web is intended for documents, not applications, and applications should be written in native code, not JavaScript. In fact, queue them too because there seem to be so many of them.

        • by turgid (580780)
          It will be a sad day indeed when the majority of the world does its business in JavaScript.
        • Re: (Score:3, Interesting)

          by jeremyp (130771)

          Who cares? The fact is that most of the web is documents, not applications. Javascript performance is largely irrelevant when rendering Wikipedia or Google. So why does anybody care about its speed?

    • by phantomfive (622387) on Saturday August 14, 2010 @04:48PM (#33252594) Journal
      It's looking towards the future. HTML 5 is designed to replace Flash, but it can't do it if Javascript is slow. Performance is going to be an important differentiator in browsers, for how well they are able to run web apps (of course, if all browsers speed javascript up to roughly the same performance level, it won't be a differentiator).
      • Performance is going to be an important differentiator in browsers, for how well they are able to run web apps

        Well, that knocks Firefox out of the running. Slow as a snail, memory hog... I gave up FF for Chrome / Safari (WebKit) many moons ago. Until they get a handle on memory management and the speed of their JS engine, I'll not return.

    • by bjourne (1034822) on Saturday August 14, 2010 @05:04PM (#33252702) Homepage Journal

      I know nothing about cars so I can't give you a car analogy, sorry. However, javascript performance isn't very important at all unless "the page" really is a full javascript application ala gmail. The reason for that is that you delay the javascript execution until after the whole page has rendered by hooking up your code with the body onload event. This avoid the page lockups you can encounter on badly coded pages where the browser can't render the page before the javascript has been run to completion.

      Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.

      • by Anonymous Cowpat (788193) on Saturday August 14, 2010 @05:33PM (#33252830) Journal

        I know nothing about cars so I can't give you a car analogy, sorry.

        You must be new here...

      • Re: (Score:2, Troll)

        by fast turtle (1118037)

        Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.

        And that's exactly why I use NoScript and white list only those pages that need JavaScript working. IMO the damn advertisers are the worst ofenders for using jscript wrong and I figure they can eff off and die because I've got no interest in supporting their business model.

      • In the case of ad networks, the actual running time of the javascript is rarely an issue. The biggest problem is that when the browser encounters a script tag on a page, it stops rendering until the javascript has fully downloaded and run (because, as you say, of things like document.write). So the biggest factor in this case is how fast the script downloads, and a lot of ad servers are so overloaded, this can take tens of seconds, making the page appear much slower.
    • Re: (Score:3, Interesting)

      by X0563511 (793323)

      I don't know about you, but the only time a page doesn't load instantly is when it has large content waiting for data to come down through my Internet "Service" "Provider" or chew on some Javascript. I've never seen HTML take long at all, unless it's a 200k+ behemoth.

      • HTML ... a 200k+ behemoth.

        Careful gramps, your age is showing. The page your currently is 131k - a little short of what you call a behemoth. Maybe you'd call it a Hydra, or at least an ogre's big brother.

      • This post might be more informative if you specified the speed of your connection. If you happen to live next door to a university, and have access to their fiberoptic trunk - you'll seldom wait for anything. I mean, can you download movies in less than a week? Less than a day? Less than an hour?

        I can download an ISO in 12 to 20 hours, if I don't mind listening to the wife and kids bitching about the lack of internet on their machines. Throttling my download so that I don't have to listen to their bitc

        • by X0563511 (793323)

          I pay $30/m for Comcast Cable. Burst speeds do reach up to 1mb/s on occasion - real throughput seems to live around 300k/s to 600k/s.

          Connection speed shouldn't make too much of a difference unless you have something like dialup, slow DSL, or a poor vsat link. Even then, those would be content downloads hanging it up, not text. Hopefully.

    • JavaScript performance is important because everything else is already so fast you won't notice. A web browser first needs to parse the [X]HTML to construct a DOM. Any reasonably fast computer is bottlenecked on I/O doing this, even with quite a poor implementation. Then it has to build a layout tree. Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen

      • CSS table layout (Score:3, Insightful)

        by tepples (727027)

        Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen full quickly - anything off the screen just needs to be finished before the user scrolls that far down the page.

        Not always. The layout of an element further down the page can have effects higher up the page. Think of a multiple-screen-tall element using CSS display: table with inner elements using display: table-row and display: table-cell. This can be either a <div> element using a grid layout or an actual <table>; the effect is the same.

    • How important are JavaScript times to the overall speed of rendering pages?

      Try (ab)using Konqueror/KHTML as your primary/only browser for a month and you will soon get frustrated by simple things like the What You See Is What You Get on your blog software not working.

      I personally do not give a damn about JavaScript performance. It matters zero to me. JS runs "fast enough" in all browsers.

      It does matter a whole lot to me that the JavaScript on sites runs as expected.

      I do not care if a piece of JavaScript does not work slow or fast.

    • by Rich0 (548339)

      I dunno, but when I ditched firefox years ago Konqueror was the first browser I went to. The reason? Page rendering times.

      For whatever reason when opening multiple tabs firefox would occasionally go into la-la land and tab after tab would just end up frozen in a loading state (tabs that had rendered worked, new fetches were frozen). It was as if some thread held a lock keeping anything from doing anything. Then all the sudden they'd all load in rapid order (maybe 1-2 mins later). Yes, I checked the var

  • by dlenmn (145080) on Saturday August 14, 2010 @04:56PM (#33252652) Homepage

    Is work continuing on KHTML, and -- if so -- why? I mean, KHTML surely has some stuff going for it (it was the basis for WebKit), but it seems like there's a really clear winner.

    • by icebike (68054) on Saturday August 14, 2010 @05:18PM (#33252756)

      The speed changes in webkit are being backported to KHTML.

      As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison [pcworld.com] on you.

      • Re: (Score:3, Insightful)

        by dlenmn (145080)

        The speed changes in webkit are being backported to KHTML.

        Is that the actual plan? At one time, I thought the plan was an "unforking" [arstechnica.com].

        As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison [pcworld.com] on you.

        Oracle is wielding patents. If Apple decided to do that, then it wont make any difference if these are two projects or one.

    • Re: (Score:2, Informative)

      by Cley Faye (1123605)
    • Re: (Score:3, Interesting)

      by Ilgaz (86384)

      KHTML may live on (!) as System HTML renderer, help renderer, whatever renderer and for people who chooses stability/robustness over "web 2.0" things like most insane javascript performance ever!

      Not just that, Webkit stuff comes to KHTML too. They could be just a bit conservative since they have a OS (yea, minus drivers and kernel) which runs happily on 3 different architectures which has nothing to do with each other.

      You wouldn't want Konqueror to crash while you move critical files around with it, you kno

    • Re: (Score:2, Informative)

      by sombragris (246383)

      Is work continuing on KHTML...?

      It seems so. Check this [blogspot.com].

  • by Anonymous Coward

    Firefox 4 Beta 2 is so yesterday, today Firefox 4 Beta 3 is all the rage.

  • by xiando (770382) on Saturday August 14, 2010 @05:24PM (#33252786) Homepage Journal
    It must be noted that the WebKit support in Konqueror is very limited in many ways, and this may matter more to many people than a JavaScript speedboost. It does NOT, for example, allow you to run Java applets. http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/kdewebkit/ISSUES [kde.org]

    My personal opinion is that all other written-for-WebKit browsers are better choices compared to Konqueror+kpart for those who want a browser with WebKit rendering at this point.
    • Honestly, I don't know why they put so much effort into maintaining Konqueror instead of helping to get rekonq up to speed.

      http://rekonq.sourceforge.net/ [sourceforge.net]

      • ReKonq is just a browser.

        Konqueror is an extremely flexible browser, file manger and document reader. It can browser remote file systems over ftp or ssh (OK, lots of file managers can do that, but not all). You can spilt views arbitrarily - so a vertical split can emulate an old-fashioned FTP app, but you can split within those views as well.

        • Yes, but in KDE 4 Okular is now the default document reader and Dolphin is now the default file manager.

          It wouldn't be unprecedented for them to replace the default web browser with a better browser.

          Even Konquerer developers have admitted the interface is less than optimal because it tries to be all things to all people.

    • It does NOT, for example, allow you to run Java applets.

      Oh noes! Does it at least support the Gopher protocol and the <blink> tag?

      • by Ilgaz (86384)

        Well, that joke will eventually hit +5 funny but, let me tell what happened today.

        Was in market for a end user VPN account, you know they really depend on your IP to their IP speed/path. The largest and known/old VPN provider for such use has made all speed tests in Java. As I was testing something on OS X 10.4.11 Tiger (read as: OLD) and Apple stopped updating Tiger long time ago, along with security updates, I don't dare to enable "applets".

        So until the gcc451 test was finished, I was prisoned on that par

    • Re: (Score:3, Informative)

      by haruchai (17472)

      A little patience, please.

      If you check the entries on the page that you're linking to, you'll find this - https://bugs.webkit.org/show_bug.cgi?id=33044 [webkit.org]
      On that page, there are already some patches that have been submitted, although not yet reviewed and developer resources have been allocated
      to having a deeper look at the issue of getting Java applet support working.

      Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit b

      • A little patience, please... Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.

        A WebKit kpart is not new; there's been one for some time -- I made a package [launchpad.net] of it in October '09 because the one in the kubuntu repositories was out of date, so it must have been around for some time before that. Many things didn't work back then. For example it didn't integrate with KDE's password saving system. It looks like that's related to the fourth bullet on the list xiando posted -- so that _still_ may not be fixed.

        Don't get me wrong, I'm glad to see that they're making progress. However, this has

        • by haruchai (17472)

          I've long been disappointed with Konq not moving more quickly to Webkit but I think this is a tipping point for them.
          Especially now since KDE 4 has matured.

      • by RichiH (749257)

        > Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.

        Webkit has been "in" since KDE 4.3 or 4.4. I have been submitting bug reports like crazy and things have become a lot better. Yet, in 4.4.5 the Webkit Kpart degraded so badly that I had to stop using it altogether to stop Konqui Segfaulting after mere seconds of use.

        The people who think they like Webkit will find out what the seperate thread

    • by rrohbeck (944847)

      What, nobody has written a Java VM is JavaScript yet?

  • Sunspider Test [webkit.org]

    Firefox-3.5.9-Linux: 2331.6ms

    Opera-10.61-Linux: 868.2ms

    Chromium-6.0.492.0-Linux: 865.6ms

    I would have posted links to the results but apparently there were too many non-letter characters per line (even with the links inside href attribs).
  • People still use Konqueror? Even if I was running Linux, I'd be using Chrome, or Firefox, or Opera..
    • People still use Konqueror? Even if I was running Linux, I'd be using Chrome, or Firefox, or Opera..

      No, I think you have been misinformed. No one is still using Konqueror because no one ever used it in the first place. A lot of us linux users prefer Gnome to KDE, and even a ton of us who use KDE insist on something more "mainstream," like Firefox, Chrome or Opera, which are all better options, in my opinion. Konqueror's overall penetration of the web browser market is probably negligible, as its influenc
  • NASCAR (Score:3, Insightful)

    by uvajed_ekil (914487) on Saturday August 14, 2010 @11:00PM (#33254586)
    Konquerer is sort of like a NASAR Sprint Cup car - fast, but not the best tool for most jobs, and more of a novelty than something I'd want to drive every day. Some people love each of this things, and I think most of these people are silly, uneducated, and love to ignore the real world.
  • Webkit is faster than Firefox but Konqueror still crashes 2 out of 5 times when encountering streaming (Flash) video.

A committee is a group that keeps the minutes and loses hours. -- Milton Berle

Working...