Linked by Thom Holwerda on Sun 15th Aug 2010 18:22 UTC, submitted by Debjit
KDE "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."
Order by: Score:
Firefox 4 is not ready yet
by shmerl on Sun 15th Aug 2010 18:41 UTC
shmerl
Member since:
2010-06-08

Mozilla is still in the midst of planned optimizations, and integration of JaegerMonkey into Firefox 4. So it's still early to make comparisons.

See:
http://arewefastyet.com
https://wiki.mozilla.org/JaegerMonkey

Edited 2010-08-15 18:42 UTC

Reply Score: 3

RE: Firefox 4 is not ready yet
by MamiyaOtaru on Sun 15th Aug 2010 20:03 UTC in reply to "Firefox 4 is not ready yet"
MamiyaOtaru Member since:
2005-11-11

oh ok, I'll just travel to the future and grab a copy of Firefox from then, instead of being interested in how speeds compare between browsers right now

Edited 2010-08-15 20:03 UTC

Reply Score: 3

RE[2]: Firefox 4 is not ready yet
by ssokolow on Sun 15th Aug 2010 20:09 UTC in reply to "RE: Firefox 4 is not ready yet"
ssokolow Member since:
2010-01-21

I think the point being made was that it's a comparison against last year's model and a more useful comparison would have included bars for stuff typical of this generation of browser. (Chrome 5 or 6, Opera 10.50+, Safari 5)

Reply Score: 2

RE[2]: Firefox 4 is not ready yet
by shmerl on Sun 15th Aug 2010 22:12 UTC in reply to "RE: Firefox 4 is not ready yet"
shmerl Member since:
2010-06-08

Wait until Firefox 4 will be released, and compare then. The current beta is still significantly behind in performance from the planned release version.

Reply Score: 1

WereCatf Member since:
2006-02-15

Wait until Firefox 4 will be released, and compare then. The current beta is still significantly behind in performance from the planned release version.

I don't understand this mentality. It sounds just like you're just trying to defend Firefox and make it not look bad, ie. an excuse.

What's wrong with comparing _current_ development to _current_ development? There will always be something later on, you just can't ask everyone to wait until the next big thing before allowing comparisons.

Firefox v4 will come when it's ready and will undoubtedly get benchmarks done then but that's then, not now. This is now.

Reply Score: 6

RE[4]: Firefox 4 is not ready yet
by _xmv on Mon 16th Aug 2010 01:10 UTC in reply to "RE[3]: Firefox 4 is not ready yet"
_xmv Member since:
2008-12-09

firefox does not actually look bad
the article in question used firefox just because it makes it more "newsworthy" to talk of firefox

firefox is not the fastest in javascript at all, albeit they're working on it, i can't feel anything going "slow" in real life, except the initial startup.
html rendering itself is extremely competitive

Reply Score: 1

WereCatf Member since:
2006-02-15

firefox does not actually look bad

Indeed it doesn't. That's why I responded to the poster: there just is no need to jump to Firefox's defence like that. People just wanted to see how Konq-webkit compares to recent development version of Firefox and they did, nothing else. There is absolutely nothing wrong with comparing something current against another current thing, just do another comparison later on if you ain't satisfied with the current results.

Reply Score: 3

RE[4]: Firefox 4 is not ready yet
by shmerl on Mon 16th Aug 2010 02:34 UTC in reply to "RE[3]: Firefox 4 is not ready yet"
shmerl Member since:
2010-06-08

Sure, there is nothing wrong in comparing anything to anything. The point was about the language of the article, which made the comparison look like something unexpected (taking in account some expectations, that Firefox 4 is fast).

Reply Score: 1

Neolander Member since:
2010-03-08

Maybe he meant that the current release of the Webkit engine that was integrated in Konqueror has reached... well.. release quality, while development of the new engine of Firefox 4 is still in progress...

Reply Score: 2

RE: Firefox 4 is not ready yet
by KAMiKAZOW on Sun 15th Aug 2010 22:06 UTC in reply to "Firefox 4 is not ready yet"
KAMiKAZOW Member since:
2005-07-06

You behave as if you've read a different benchmark than me.
The benchmark I've read focused on the difference between KHTML and QtWebKit. Firefox was just thrown in to have a more mainstream browser as rough comparison in there. Nobody claimed "OMG QtWebKit is so fast, Firefox can never reach it".

Reply Score: 3

RE[2]: Firefox 4 is not ready yet
by shmerl on Sun 15th Aug 2010 22:17 UTC in reply to "RE: Firefox 4 is not ready yet"
shmerl Member since:
2010-06-08

It sounded like something unexpected:

Surprisingly Konqueror with WebKit is also faster than Firefox 4.0 Beta 2

If this was all about integrated JaegerMonkey - that would be interesting. Otherwise there is nothing surprising here.

Reply Score: 1

KAMiKAZOW Member since:
2005-07-06

Firefox is still not the focus of that benchmark. Konqueror with its two engine choices is.

Reply Score: 4

RE: Firefox 4 is not ready yet
by wanker90210 on Tue 17th Aug 2010 15:43 UTC in reply to "Firefox 4 is not ready yet"
wanker90210 Member since:
2007-10-26

Just wait until the webkit version that will be released after ff4.0 sharp will be released.

Reply Score: 1

Why only now?!
by usr0 on Sun 15th Aug 2010 19:21 UTC
usr0
Member since:
2006-10-27

WebKit is out for years and for years there were plans to drop the home-brewed KHTML in favor of WebKit. In fact it wasn't difficult at all. I've build a WebKit-enabled Konqueror version myself years ago.

But the KDE crew have done this step only now. And there are still people complaining about big evil corp's policies that inhibit tech progress...

Reply Score: 1

RE: Why only now?!
by ssokolow on Sun 15th Aug 2010 19:40 UTC in reply to "Why only now?!"
ssokolow Member since:
2010-01-21

As I understand it, QtWebKit didn't expose APIs required for feature parity when KDE 4.0 was released and their API stability policy requires that all APIs present in 4.0 remain throughout the release cycle, so that might have been a drag or disincentive on KWebKit development.

(That API stability policy and having been burned by an earlier GStreamer release is actually what lead to Phonon... apparently at least one GStreamer dev showed quite a lack of maturity at that development.)

Of course, API stability and functional stability are two different things. As much as I like the idea of KDE, I switched to LXDE after waiting through 4.4, still having too many bugs, and discovering that one guy in a basement can easily have a more thought out release testing plan than the KDE guys. (It also doesn't help that they see no problem with the "chuck it all out and start over" pattern that appears at every major version increment with regards to features and stability)

Edited 2010-08-15 19:41 UTC

Reply Score: 4

v RE[2]: Why only now?!
by tyrione on Tue 17th Aug 2010 03:46 UTC in reply to "RE: Why only now?!"
RE[3]: Why only now?!
by smitty on Tue 17th Aug 2010 06:42 UTC in reply to "RE[2]: Why only now?!"
smitty Member since:
2005-10-13

I'm not sure i understand your point.

The KHTML devs split in half a while ago - half continued development on it, while insisting that Apple and Webkit were evil and not integrated into KDE well enough to replace khtml.

The other half went to work for Trolltech integrating Webkit into Qt. Eventually, those same people, along with a few others from the community that were trying to use Webkit in their projects, finished the integration work with Webkit/KDE.

Reply Score: 3

RE: Why only now?!
by _xmv on Mon 16th Aug 2010 01:12 UTC in reply to "Why only now?!"
_xmv Member since:
2008-12-09

i'd like to point out even if it's easily forgotten that KHTML has had a HARD time getting proper code from Apple, so yes, they're big evil corps, thankfully the license prevailed and we now have a very good engine which is getting contributions from everywhere.

And that's why *GPL* OSS > x (call this flamebait if you wish, it stands true here)

Reply Score: 2

RE[2]: Why only now?!
by KAMiKAZOW on Mon 16th Aug 2010 02:34 UTC in reply to "RE: Why only now?!"
KAMiKAZOW Member since:
2005-07-06

Much code in WebKit has been completely replaced since KHTML. That code is BSD-licensed without the need to release it.
Collaborative open development is just beneficial for all involved parties, including Apple.

Reply Score: 2

RE[2]: Why only now?!
by bousozoku on Thu 19th Aug 2010 00:57 UTC in reply to "RE: Why only now?!"
bousozoku Member since:
2006-01-23

i'd like to point out even if it's easily forgotten that KHTML has had a HARD time getting proper code from Apple, so yes, they're big evil corps, thankfully the license prevailed and we now have a very good engine which is getting contributions from everywhere.

And that's why *GPL* OSS > x (call this flamebait if you wish, it stands true here)


Ahhh, yes "proper code", whatever that is. You mean that the code wasn't returned in the same messy state that Apple had to start with it? That it was in a completely different messy state?

Yes, they returned the code in a different way than the KHTML developers wanted and there was much moaning, despite wholesale improvements in the code.

Reply Score: 2

Comment by Kroc
by Kroc on Sun 15th Aug 2010 20:11 UTC
Kroc
Member since:
2005-11-10

So, are there still people defending kHTML and painting Apple as the villain?

Reply Score: 1

RE: Comment by Kroc
by mat69 on Sun 15th Aug 2010 20:40 UTC in reply to "Comment by Kroc"
mat69 Member since:
2006-03-29

KHTML has to stay for the 4.X cylce. Binary compatility.

And further good performance does noone make more or less evil. You mix things here just for trolling, right?

Not even to forget that as long as people are working on KHTML ...
The problem the last few years with the Webkit integration was that not many people were working on it.

Edited 2010-08-15 20:43 UTC

Reply Score: 7

RE: Comment by Kroc
by Elv13 on Sun 15th Aug 2010 21:33 UTC in reply to "Comment by Kroc"
Elv13 Member since:
2006-06-12

Back in KDE3 days, KHTML was the best OSS rendering engine around. It was the second browser to get 100% ACID2, long before any other one. Code was backported from pre-webkit safari dumps and it was working with all websites. It is not the case anymore, the web is more complex and evolving faster than it was. You have to give credit to kHTML instead of bashing it, it's days are over, but it was an OSS masterpiece.

Reply Score: 11

RE: Comment by Kroc
by KAMiKAZOW on Sun 15th Aug 2010 21:50 UTC in reply to "Comment by Kroc"
KAMiKAZOW Member since:
2005-07-06

So, are there still people defending kHTML and painting Apple as the villain?

That position was only taken by the KHTML team (maybe still is -- I don't know and frankly I don't care). It never was the opinion of the majority within KDE.

Reply Score: 3

RE: Comment by Kroc
by Soulbender on Mon 16th Aug 2010 01:22 UTC in reply to "Comment by Kroc"
Soulbender Member since:
2005-08-18

Appel is a villain regardless.

Reply Score: 3

RE: Comment by Kroc
by Neolander on Mon 16th Aug 2010 10:55 UTC in reply to "Comment by Kroc"
Neolander Member since:
2010-03-08

Sure, Apple are still the villains ;)

If I remember well, the KDE guys had to threaten them with legal actions before they make an (incomplete) release of Webkit's source. So knowing Apple, we can easily envision that without the KHTML team, Webkit would be yet another Trident ;)

Reply Score: 2

RE[2]: Comment by Kroc
by KAMiKAZOW on Mon 16th Aug 2010 13:52 UTC in reply to "RE: Comment by Kroc"
KAMiKAZOW Member since:
2005-07-06

KDE never threated Apple with any legal action regarding WebKit.
From day one Apple followed the LGPL by releasing the sources. However, WebKit was not following an open development model with a public repository etc.
Development model and licensing are different things and no FOSS license I'm aware of forces open development.

Before forking KHTML Apple was an active contributor to Mozilla -- Chimera/Camino to be exact. So the involved people already knew how to be part of a community project.

Apple wasn't a FOSS poster child by not using public development right from the start, but Apple was also not violating any license.
You must be confusing the matter with NeXT (Steve Jobs' old company that was bought by Apple in the early 1990s) who created a proprietary fork of GCC in the 1980s or so and then was visited by a few FSF lawyers.

Reply Score: 3

ISP to website
by John Blink on Mon 16th Aug 2010 00:56 UTC
John Blink
Member since:
2005-10-11

Serious question: Is this difference mostly negated by the performance of your Internet connection?

Reply Score: 2

RE: ISP to website
by KAMiKAZOW on Mon 16th Aug 2010 02:32 UTC in reply to "ISP to website"
KAMiKAZOW Member since:
2005-07-06

It depends. If a web site has few scripts but many graphics, yes.
If a web site uses many scripts and few graphics (many Google services come to mind), it can be very noticeable.

JavaScript execution is not the only client-side performance factor. Complex HTML and CSS rendering also takes its performance toll even after all web site files have been downloaded (eg cracked.com is totally unusable with my Firefox installation).

Reply Score: 2

RE[2]: ISP to website
by John Blink on Mon 16th Aug 2010 03:34 UTC in reply to "RE: ISP to website"
John Blink Member since:
2005-10-11

Thanks for that info.

Also cracked.com not bad, but performance seems okay for me ;)

Reply Score: 2

Ehm.
by emilsedgh on Mon 16th Aug 2010 07:04 UTC
emilsedgh
Member since:
2007-06-21

KHTML is being actively maintained and developed. It support most of today's rendering engine features and is not 'far far behind' others like many claim.

Most of the issues are not because khtml is bad, but because website dont let it work. For example, gmail, google maps and most other google websites will work just fine if you change your user agent.

Also, khtml is not there just to keep binary compatibility. Its there because its an actively maintained and developed KDE project which is very well intergrated into KDE.

(Im not a khtml developer, I follow its development however).
http://khtml-konqueror.blogspot.com shows khtml's activity.

Reply Score: 2

RE: Ehm.
by KAMiKAZOW on Mon 16th Aug 2010 09:17 UTC in reply to "Ehm."
KAMiKAZOW Member since:
2005-07-06

This benchmark is not about how many web standards are supported but how fast KHTML's JavaScript execution is and in all posted benchmarks KHTML is far behind.

Reply Score: 2

RE[2]: Ehm.
by emilsedgh on Mon 16th Aug 2010 09:21 UTC in reply to "RE: Ehm."
emilsedgh Member since:
2007-06-21

I wasnt talking about the benchmark. I was talking about khtml vs. others in general.

Reply Score: 1

RE[2]: Ehm.
by Carewolf on Mon 16th Aug 2010 17:17 UTC in reply to "RE: Ehm."
Carewolf Member since:
2005-09-08

Yeah, selecting tests are good. So do you like javascript speed or rendering speed: http://ie.microsoft.com/testdrive/Performance/01FlyingImages/Defaul...

Reply Score: 1

No, they don't
by Bill Shooter of Bul on Mon 16th Aug 2010 16:48 UTC in reply to "Ehm."
Bill Shooter of Bul Member since:
2006-07-14

I've tried making khtml work with gmail and google docs. It sorta works, but often many parts of it do not work correctly. I think the biggest problem, as evidenced by this article, is that its comparatively super slow at javascript

Reply Score: 2

They've got a long way to go still
by tyrione on Tue 17th Aug 2010 03:44 UTC
tyrione
Member since:
2005-11-21

If they're getting just over 1000 ms for the Sunspider test they've got a long way to go.

I'm getting 480ms on a Pentium D 940 4GB Ram with Epiphany Trunk.

I'll have to test Konq 4.5 when Debian releases KDE 4.5 after Debian 6.0 is out the door.

Reply Score: 1