i tested it with 0.097ccfme by v8 benchmark suite

but the experiece seems not so much difference between the two for daily use.

i know that number is not so important, but how long can we catch it up?



and fx4.06

K-Meleon can only catch up to Fx4 if it upgrades to the newest Gecko that Fx4 is using, which is Gecko 2.0.

If I am correct, upcoming KM 1.6 uses Gecko 1.9.1 and upcoming KM 1.7 uses Gecko 1.9.2, which will not be anywhere close to the performance of Fx4 with the interface and garbage collector improvements, not to mention the JaegerMonkey Javascript engine.

It will take a subsequent version of KM based at least on Gecko 2.0 before KM can catch up to Fx4.

For more details, you can refer to the K-Meleon and Firefox columns in the Gecko Usage Chart at the end of:
http://en.wikipedia.org/wiki/Gecko_(layout_engine)



Edited 1 time(s). Last edit at 05/15/2011 07:09AM by bksening.

And also, the V8 benchmark link in your original post is out-of-date. It points to the ver.5 V8 test, but the current one is the ver.6 test.

This link should be used for the V8 benchmark, which will always point to the current test version:
http://v8.googlecode.com/svn/data/benchmarks/current/run.html

Much clear now, thanks for explaination.

i choose v8 test, because newest test always freeze my km.

Quote
chinarobin
Much clear now, thanks for explaination.

i choose v8 test, because newest test always freeze my km.

try doing the test with Fx5 when that one comes out later this june.

Quote
4td8s

try doing the test with Fx5 when that one comes out later this june.

scratch that. try the latest Firefox 7.0a2 aurora build. FF7 loads faster, runs faster than any version of K-meleon I've used.

The possible better speed seems for me mainly
concerning faster javascript execution, caused
by a faster Javascript engine.
For me personally, this is not that important,
as I turn off javascript most of times.
I use it only sporadically if it is absolutely
necessary.
The features that make K-Meleon more interesting
for me than the other browsers is the possibility
to adapt it to my personal wishes using the
menus and macros, and that is where scripting
is important for me.
A webpage should be usable satisfactorily without
any scripts.
Even Youtube seems to have learned that, as
the flash files load now without javascript,
which is completely unnecessary and only
a source of unwanted smuggling in of malware.
Flash works basically without javascript.

Fred

Quote
Fred
The possible better speed seems for me mainly concerning faster javascript execution, caused by a faster Javascript engine.
For me personally, this is not that important, as I turn off javascript most of times. I use it only sporadically if it is absolutely necessary.

Ditto!

Quote
Fred
The features that make K-Meleon more interesting for me than the other browsers is the possibility to adapt it to my personal wishes using the menus and macros, and that is where scripting is important for me.

The Browser You Control Besides, the most lightweight one!

Quote
Fred
A webpage should be usable satisfactorily without any scripts.
Even Youtube seems to have learned that, as the flash files load now without javascript, which is completely unnecessary and only a source of unwanted smuggling in of malware.

Not only a source of smuggling in malware but also one for nerving adds and snooping.

Quote
Fred
The possible better speed seems for me mainly
concerning faster javascript execution, caused
by a faster Javascript engine.
For me personally, this is not that important,
as I turn off javascript most of times.
I use it only sporadically if it is absolutely
necessary.
The features that make K-Meleon more interesting
for me than the other browsers is the possibility
to adapt it to my personal wishes using the
menus and macros, and that is where scripting
is important for me.
A webpage should be usable satisfactorily without
any scripts.
Even Youtube seems to have learned that, as
the flash files load now without javascript,
which is completely unnecessary and only
a source of unwanted smuggling in of malware.
Flash works basically without javascript.

Fred

Fred,

Couldn't agree more. For my tastes, the Privacy Bar toggle for JavaScript allows me to surf with javascript off until such time as I run into a site that requires it to be on and then I can make a reasoned guess as whether or not I sould enable it for that specific case.

N

In real life (not in synthetic tests) KM isn't slower than any FF.

Yes, FF developers make real success in optimizing their product and Yes, FF is better in JS-support and processing. And as average user I do (!) need JS sometimes.

But we can't say KM is slower for at least 2 reasons:
1) 10x difference in test doesn't mean real 10x gap. KM don't support some new JS-features at all and this leads to big misses in scores. Summarize points is not the best way of estimating such things :-) Most sites don't use this features at all.
2) JS isn't browsing speed bottleneck. They are html-parsing, css one, # of simultaneous tcp/ip-connections, computer RAM work, GUI speed (XUL or Win native) and so on but not JS handling!
So in real life after opening some tabs FF (and moreover installing many extensions) begins to slow down and lose responsivness much earlier, than KM does.

So, the only thing, which I must say to Fred and all KM developers is, though, veru important.
I like adapting possibilities of KM but as usual user I really need more simple, say visual, tools for configuration needs.
Average non-technical user likes to have GUI for toolbars setup, session management and (!) transfer (as there are many actual branches of developing KM), prefs editing and so on.

It's a real pain when you just change the skin - and all toolbars fall to pieces and you cannot take them back as half of buttons are absent... Etc.
So, we, mass user, need these tools. KM needs them. It must became more user-friendly and only then it will get a chance for survive.

More users -> more attention -> more new developers. Otherwise...

Quote
rodocop
2) JS isn't browsing speed bottleneck. They are html-parsing, css one, # of simultaneous tcp/ip-connections, computer RAM work, GUI speed (XUL or Win native) and so on but not JS handling!

What I marked in bold it's not exact...

Indeed, when you disable javascript (and as I said in another post I'm tending to do it often lately) you find that the page renders (that you can say browsing speed instead), quite faster.

Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.

Talking only about K-meleon, if you put 1.1.6 (which I'm still using) and 1.6 without javascript (and forgetting that 1.6 has fixes for HTML4 and supports part of new HTML5), their respective GRE engines are hand to hand.

Developers would say other thing and they would be correct, but, for the average users, with the above conditions, a page render is just a matter of milliseconds.


For the skins, you should make a suggestion for development. I agree with you. It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.

In other words, standardize them.

Quote
JohnHell

Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.

Maybe you're right. Maybe...

But in real life I take one of the most AJAXed web-sites - webOS (eyeOS.org) and gave KM (1.6b2) and FF (4.0.1) a try on this sample. I can't see any FF advantage in speed of working there. Otherwise, KM was sometimes notably faster.

Per contra, old KM just refuses to load some JS-rich pages and this is real restriction that leads to mass migration on the new version. But if KM works on page (on REAL existing page!) it does this not slower than FF right now.

Possibly, there are some rare exclusions, but I didn't meet them yet :-)

Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.

This is one way. And reasonable way. But regardless of standard presence my query deserves attention too: even if we get unified toolbar, we also need GUI tool for configuring it, as in FF.

Quote
rodocop

Quote
JohnHell

Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.

Maybe you're right. Maybe...

But in real life I take one of the most AJAXed web-sites - webOS (eyeOS.org) and gave KM (1.6b2) and FF (4.0.1) a try on this sample. I can't see any FF advantage in speed of working there. Otherwise, KM was sometimes notably faster.

But we are comparing there a very similar GRE version, or, at least, both have JIT (Just In Time) new JS engine.

Quote
rodocop
Per contra, old KM just refuses to load some JS-rich pages and this is real restriction that leads to mass migration on the new version. But if KM works on page (on REAL existing page!) it does this not slower than FF right now.

Possibly, there are some rare exclusions, but I didn't meet them yet :-)

Yes, that's true. (But remember that if KM refuses some JS sites is because of JIT version/implementation on that version)

But with javascript enabled, we could say something like:

KM1.6b2 against FF4.0: very similar
KM1.6b2 against FF7.0: notable differences
KM1.1.x-1.5.x against FF4.0: notable differences
KM1.1.x-1.5.x against FF7.0: maybe no words to describe
KM1.1.x-1.5.x against KM1.6-1.7: huge difference.

Without javascript enabled, not very important differences (beyond display layout because of HTML version implementation).

Quote
rodocop

Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.

This is one way. And reasonable way. But regardless of standard presence my query deserves attention too: even if we get unified toolbar, we also need GUI tool for configuring it, as in FF.

That could be an interesting suggestion: some kind of a toolbar wysiwyg GUI editor/customizer



Edited 2 time(s). Last edit at 07/14/2011 08:36PM by JohnHell.

Quote
JohnHell

Quote
rodocop

Quote
JohnHell
Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.

Maybe you're right. Maybe...
But in real life I take one of the most AJAXed web-sites - webOS (eyeOS.org) and gave KM (1.6b2) and FF (4.0.1) a try on this sample. I can't see any FF advantage in speed of working there. Otherwise, KM was sometimes notably faster.

But we are comparing there a very similar GRE version, or, at least, both have JIT (Just In Time) new JS engine.

Quote
rodocop
Per contra, old KM just refuses to load some JS-rich pages and this is real restriction that leads to mass migration on the new version. But if KM works on page (on REAL existing page!) it does this not slower than FF right now.
Possibly, there are some rare exclusions, but I didn't meet them yet :-)

Yes, that's true. (But remember that if KM refuses some JS sites is because of JIT version/implementation on that version)
But with javascript enabled, we could say something like:
KM1.6b2 against FF4.0: very similar
KM1.6b2 against FF7.0: notable differences
KM1.1.x-1.5.x against FF4.0: notable differences
KM1.1.x-1.5.x against FF7.0: maybe no words to describe
KM1.1.x-1.5.x against KM1.6-1.7: huge difference.
Without javascript enabled, not very important differences (beyond display layout because of HTML version implementation).

Quote
rodocop

Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.

This is one way. And reasonable way. But regardless of standard presence my query deserves attention too: even if we get unified toolbar, we also need GUI tool for configuring it, as in FF.

That could be an interesting suggestion: some kind of a toolbar wysiwyg GUI editor/customizer

Sorry, what?
Considering long term browser usage and bandwidth, no Firefox version is faster than Kmeleon. In fact, Firefox 4.0.1 and Firefox 5.0.1 are slower and poorly efficient than Kmeleon 1.5.4 and Internet Explorer 9. I'm writing this post with Firefox 3.6.19 with 14 extensions enabled, and its performance and stability is incredible. Gecko branch 1.9.2.x is the best so far. o.O

margarita,

<<Considering long term browser usage and bandwidth, no Firefox version is faster than Kmeleon. In fact, Firefox 4.0.1 and Firefox 5.0.1 are slower and poorly efficient than Kmeleon 1.5.4 and Internet Explorer 9. I'm writing this post with Firefox 3.6.19 with 14 extensions enabled, and its performance and stability is incredible. Gecko branch 1.9.2.x is the best so far. o.O>>

Agree... After KM, I only run firefox portable versions and FF 5.0.1 has been a headache. IF you go into about config and turn off lots of the new "features" it runs faster, but still not good and several of my extensions won't run now.

N



Edited 1 time(s). Last edit at 07/15/2011 12:47PM by ndebord.