Gecko, like every other Open Source project, is getting smaller and faster with every release. This is the nature of OS development, and I love it.
Look, compare Firefox, Mozilla Suite, Open Office, KDE, Gnome, Kernel, etc. Every piece gets faster with every release. If not faster, than it stays in 0 point, if it’ll regress in performance, it’ll get faster than before in the next one, because automated performance systems will catch the rise and someone will investigate that part of the code, cleaning it, and optimizing.
For Mozilla, you can look at build-graphs.mozilla.org and compare the results in, say 360 days.
Of course, it doesn’t mean that OS is faster than proprietary software everywhere. There are many other issues that can make it opposite, but comparing two pieces of software requires much more than simple timer. For example comparing browsers performance is very hard. IE will start with the OS, Opera is pure browser, while Firefox is Gecko and Gecko is full cross-platform RAD environment. Which one is faster, depends on the test and everything might make the difference, so, to make a precise statement about performance, you need very complex term. Like “App X in ver Z is faster than Y in ver U on Linux, in loading code V when not using cache”, so I think that this kind of comparison is more a journalist job (who can say “App X is reaaally fast” and noone will force them to prove their claims), but for us, most important is to compare our versions, make sure that every next is faster and seek&destroy issues that hits the default user hardest. (it doesn’t apply to pre 1.0 versions. Yes, Flock will have to be optimized before 1.0 ;)).
One example of this is Gecko code bloat. While we’re getting faster, cleaner and better overall. While we solved many issues and created Firefox that unbloated the Gecko Browser thing, we’re still far away from solving this problem. Jesse Ruderman recently blogged about progress in fixing Firefox 1.5 leaks that seems to be more affecting user than Firefox 1.0 ones!
With time, Gecko platform seems to be used wider and it means that any leak in Gecko will appear in many places striking at the user with multiplied power, but also it means that if Gecko platform design patterns are allowing or provoking to introduce mem leaks in Gecko based apps, then we’ll have a really big problem in the future.
And it seems that Gecko is, at least, not doing enough to prevent coders from bloating, making it harder than it could be not to leak. Robert O’Callahan, wrote a blog post with an example of a bloat and a leak in SVG code. It’s just an example, but it’s a great start point to talk about what Gecko devs can do to make coding without a leaks easier.
The response, from Brendan Eich, is very interesting. He proposed 3 ideas to cure the situation and especially the first two of them are exactly what I was waiting for, while the second is the answer for my biggest Gecko code issue. Lack of exceptions.
I love Java, because of it patterns and syntax. I don’t code in Java too much, because I’m not the best Java coder, and I know that Java “can be slow”. But exceptions are the little cute things I learned during Java coding, that makes my life simpler.
I know the current reasons against them, but I think that whole this C++ portability guidelines are very outdated.
It seems that this document was not edited (beside of typos) since 1998. Seven years is quite a lot in our world. We’re now supporting other platforms (MacOS9?), Gecko has slightly different purposes, Mozilla has a bit different vision, there is Firefox, Gecko is used on amazing amount of user computers and I think that it’s a great time to start discussing this guidelines points. How much we want sacrifice to support some odd and obsolete platform? Is it worth to slow down coders and rise the leak risk to support it? What about overall performance, code readability, etc? How much could we win if we’d be using OOP patterns?
Yes, I mean, I hope that exceptions usage discussion is the first step on the road to Mozilla 2.0 platform.
4 replies on “Gecko is moving forward. Exceptions anyone?”
Gecko could be part of a space ship for me… I don’t care. I would like Firefox (and Thunderbird!) to be fast. Maybe even faster than IE or Opera…
I agree that supporting obsolete platforms isn’t reasonable. On the other hand… Why should I, as an average user, excuse myself with words “My Firefox/Tb isn’t as fast as other apps, but hey! It’s a part of Gecko!”. So what? I think the devs shouldn’t tell everyone why Fx/Tb is slow, but actually do something about it.
Firefox 1.5 based on Gecko 1.8 was supposed to be much faster than Fx 1.0.x and it isn’t. Maybe slightly faster but, for sure, not much faster. So I would like to ask You (as a Gecko dev) – where’s the progress?!
I do agree that “Firefox is built on top of Gecko” is not an excuse. I do agree that for user it does not matter, but why I claim that statement is because comparing speed of Firefox and Opera is very hard. It depends on the test, I know people who claims that Fx is way faster than Opera for them, I know people who see no difference, and I know people who find Opera way faster. I know people who find Fx 1.0 faster than 1.5, and people who find 1.5 faster, hell, I know tests that can prove all of those statements!
The progress is in the point in which we receive feedback that clearly states that “in most cases, users see performance win during switch from 1.0 to 1.5”. In your case, it may be no difference at all, but I think that I can assume that you’re the rare case.
And I find it a prove that devs “do” sth to make Firefox/Gecko faster.
Well, I said firefox is “Maybe slightly faster but, for sure, not much faster”. I can see some improvements and I agree Firefox 1.5 is faster than Fx 1.0. But still it isn’t what it supposed to be.
Frankly speaking, I’ve expected more out of Firefox 1.5. I’m not a “disappointed user” – I was hopeing Fx 1.5 will be much faster than it’s predecessor. Yeah, it’s still faster (I can see that!), but not that much. You (as the Gecko dev community) said previously (around Fx 1.0) that next Gecko browser (refering to Fx 1.5) will be greatly faster [maybe even at Opera level as a guess].
So I think I’m not that “rare case”. The progress (for me) isn’t that big. I’m just sceptical about this “Gecko optimizing” stuff. I’ll calmly wait for Gecko 2.0-based browser and than see what You’ll come up with. I hope You’re going the right way with Gecko ;-).
I don’t see corellation between your explanation and statement “So I think I’m not that ‘rare case'” – I said, some people see no diff, some see a small one, some others see a big one. Most feedback confirms that the common case is the last one.