Netscape 6 Vs. 4.7x

rafa writes "Linuxworld has an informal comparison between Netscape 6, Mozilla, Opera and Netscape 4.7 with focus on resource usage. It reflects what I've been experiencing with Mozilla." A lot of this is well known, but the article does a good job of bringing it all together.

Comments

Re:Programmers Make Computers Slower Year by Year

[amccall]

More features? Or bad programming combined with bad languages?

Years ago the WordPerfect for Windows 5.1 was released. A WYSIWYG word processer that ran with 8 mb ram, and about 40 meg hard drive space. The fact is: there is no reason that WinME should take 550 Meg alone on my hard drive.

I'll grant you that features creep in, and users demand more and more and more features. But, newer programming classes fail to teach students some very basic important things. And what I speak of, is the often repeated line, that I've heard spoken in the classroom, and by a great many professional programmers, "RAM is cheap."

Coding is taking less and less effort, not more. Any fool with a copy of Visual Basic or Visual C++, can create a passible text editor. Compare this to the days of hand optimized assembly, where one must stretch the processor beyond its current capabilies, getting every ounce of RAM out as possible. Intelligent, well thought out designs, were the only way you could create a solution that would run well.

Now, Linux is one of the few enviroments where talented programmers have joined together to create something nice. In terms of requirements, the Linux world is moving at a much slower pace than most other industries. It is actually possible to runt the latest version of slack on a 486DX4-100 with 24 mb of ram, use an older version of netscape(or mozilla), and have things feel a bit slow, but the system be usable. This was the configuration of my Compaq laptop, which I used until I sold a week ago. :P

But their is much software where, the often repeated statement, "RAM is cheap", pops up. Even in Linux. I find the whole situation disgusting myself. One should not justify not thinking fully through a program with this qualification. Clever algorithems, thoughtfull code, and interesting tricks are no longer allowed. Coding has begun to become something for the braindead. And the sad thing is, that many corporations will hire these pimple faced teen VB programmers that have no knowledge of algorithem analysis, and have little to know experience writing anything else than yet another Visual Basic Calculator.

Take Responsibility for Your Code

[goingware]

I want to assert very firmly that the above was not a troll. I meant it very seriously and it is something that I have been discussing and posting widely on newsgroups and mailing lists for years.

I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:

If you don't take pride in your work you have no reason to be here.

This was back in my bad old days of being a college dropout, hungry with no idea what I was going to do for a career. I told him I thought that would be a terrible place to work, the boss would always be bugging you to work harder.

But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.

And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)

I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.

I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?

I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.

Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.

My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.

While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.

A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?

I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.

The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.

At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.

I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.

Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.

My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks

Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.

Michael D. Crawford
GoingWare Inc

Using top to count memory usage?

[srichman]

Uh, doesn't adding memory totals from top give an inaccurate picture of real memory usage because it counts shared pages multiple times?

E.g., if I fork() (which is pretty much the same as making a new thread in the Linux world), all the text pages that are shared will be listed under the memory total for both the parent and child process in top. If I sum the memory usages, then, I'm counting the shared pages twice.

Which can give an unfair appraisal of the memory hunger of a multithreaded program.

Re:Using top to count memory usage?

[Anonymous Coward]

Uh, doesn't adding memory totals from top give an inaccurate picture of real memory usage

Yes, absolutely it does. 4.7 is not multithreaded. The reviewer has no clue and the review is utterly pointless since it focuses almost exclusively on the memory question.

The reviewer must be one of those web "designer" types.

This is only a story because organizations, Linuxworld and Slashdot, are run by technologically illiterates. Really disgusted with the level of professionalism around here.

Anyway, I use nightly builds of mozilla and prefer them to Netscape 4.7 My machine will thrash a lot sooner with 4.7 than it will with mozilla.

That being said, Mozilla still sucks on Linux compared to W2K and solaris. I suspect it has something to do with silly linuxthreads which, of course, Linus will never change because he wrote them and they are therefore ...

B E S T T H R E A D S E V E R.

yay!

[vsync64]

Okay, now that my First Post! is out of the way...

Quite honestly, I've recently decided that NCSA Mosaic is still the best browser out there. I've got an x86 box at work, so I downloaded the (statically linked, thank goodness) binary and messed around with it.

Whoa. Nostalgia trip.

Thing is, though, it's got so many things that newer browsers don't even bother with. Like making clicked links dashed instead of solid underlined. (Kinda relevant for those color-blind users mentioned a while back.) And allowing you to select fonts for each heading level (don't think it's in that version, but I remember doing that in Mosaic on Solaris). And letting you quickly flip between a fontset for the whole document.

Oh yeah, and Mosaic is fast. Maybe that's because it focuses all its resources toward actually displaying HTML, and not trying to turn itself into some kind of sick Turing machine/security hole.

A few updates would be nice... Cookies, SSL, maybe style sheets. But overall, I just wish people would bother to consider all the "accessability features" and "performance enhancements" that always existed, but were simply forgotten.

I am in fact a developer, here's my resume

[goingware]

Well, are you a developer?

I'm typing this from my workstation at my client's office, a web application company (I've clocked out). I'm using whatever Netscape came from the Debian site when I updated my software on Monday when I started.

Read about my laptop which was my main development machine for most of the last year. It boots NT, Slackware and BeOS.

You can read my resume - note the long list of products I've shipped, and keep in mind I haven't been keeping that list up to date. See the long list of projects I've done in the two and a half years I've been a consultant.

Note that among the jobs I've held was Senior Engineer at A Big Fruit Company where I held the role of "Debug Meister" - I did low-level debugging and in fact performance tuning of the Mac operating system.

When a tester found that an application would crash under a new system build and they didn't understand what component was at fault, it came to my team (Traditional OS Integration, formerly known as the Blue Meanies). We would track down the bug and assign it to the right engineer or fix it ourselves.

Note that sometimes, probably half the time, the bug was due to a third-party app bug, and we determined this purely by running MacsBug, an assembly level debugger, inside the app and system software. We had the entire Mac OS source code at our disposal but this wasn't usually readily available when you were visiting a crashed Mac at a tester's cube so you just had to know your MacBug.

I use and contribute to open source. My latest effort was aiding the author of the ZooLib cross-platform application framework in releasing his library under the MIT License; I worked with Andy Green for a year to test his code by developing a product with it and led a beta test of developers who also developed products with it.

I found ZooLib to be an incredibly enlightening example of well-architected, efficient and compact code for what it does. Just using it and reading the source code increased my own abilities as a programmer and architect tremendously.

You can read some of my thoughts on the business and technique of programming at GoingWare's Bag of Programming Tips

Linux is better than most as far as efficiency is concerned, but don't get me started about reliability and ease of use.

As for what I think is a well engineered OS, try the BeOS but you don't want to get involved with the company.

Read why I think developers need to take back control of their lives from operating systems vendors and how I think they ought to do it. If you really want the full-bore opinion, read The Cross-Platform Manifesto

So yes, I am in fact a developer, thank you. It's just that I maintain high standards and I like to encourage others to do so as well.

Michael D. Crawford
GoingWare Inc

Re:Not fair!!

[eam]

You should never blame an application for crashing an OS. An OS should never crash as a result of some bug in an application. If it does, the problem is with the OS.

Programmers Make Computers Slower Year by Year

[goingware]

Even while our friends at Intel, Motorola and IBM do the most amazing things to speed up computer hardware (and don't forget our friends at Adaptec with the blazing 29160 SCSI Ultra160 Host Bus Adapter), programmers consistently work harder year after year to steal from the end user the gains that they might otherwise have from purchasing new hardware.

This leads to the ridiculous situation that an old computer runs slower and slower as new software is loaded on it, until you finally have to buy a new one just to run at all.

It's not just that you have the perception that your computer of old is running slower than the new computers because it was less zippy when you bought it, but because the regressive performance dehancements of operating systems and bloated applications really do make your computers run slower.

Note that I used to run SlackWare and Apache on a 100 MHz 486, serving up web pages (admittedly with a light load) while I used X at its console - and it worked fine. But when I loaded Windows 95 on it it was dog slow. There's no question of running Windows 98.

I had a 233 MHz Pentium II with 32 MB of Ram that I ran BeOS 3 for Pentium on. It worked great - I shipped Spellswell for BeOS Intel with this. But when BeOS 4 came out and they switched to Elf format, I had to upgrade to 96 MB because I couldn't run a compile and read my email at the same time.

Later I installed a near-final beta of Windows 2000 server on this machine. I intended to use it to develop a Java GUI app under CodeWarrior for Windows. To get the machine to run at all - not even running CodeWarrior - I had to add another 128 MB of RAM for a total of 224 MB. The machine was dog slow even after the memory upgrade.

There is no excuse for this. New features should not come at the expense of performance, and each new release of both operating systems and applications should be both faster and take up less space, not more. If substantial new features have been added then there may be cause for a little more code size but certainly not what we see in practice, such as what was listed in the Netscape 6 review.

Why does this happen?

One thing is because programmers are lazy, and if their code runs slow they assume the user will just get a faster machine. But friends, the user wants to buy fast hardware so they can actually run fast, not just so they can run at all.

Pressure to ship a commercial product makes managers fail to support efforts to do substantial performance tuning, especially tuning that is not localized but would require substantial rearchitecture.

And finally a lot of people just don't know how to architect or code. I think we could all benefit from learning and writing some assembly, so we could really understand what our software is doing.

Maybe then we could strip out some of the thick layers of software bureaucracy that lies between the user and his cpu.

Michael D. Crawford
GoingWare Inc

Re:Programmers Make Computers Slower Year by Year

[dbarclay10]

I understand what you mean, but you also don't understand a lot of things. I'll try to correct you a point for point basis.

programmers consistently work harder year after year to steal from the end user

I think we both know that developers arn't laughing maniacally, saying, "Haha! They'll never be able to run this!"

Note that I used to run SlackWare and Apache on a 100 MHz 486, serving up web pages (admittedly with a light load) while I used X at its console - and it worked fine. But when I loaded Windows 95 on it it was dog slow. There's no question of running Windows 98.

Don't compare apples to oranges. Windows 95/98 had a lot more things running that Slackware did, even if you didn't see them running. *You* may not have used them, but a lot of people would have.

Okay, anyways, I'm just going to skip ahead a bit. We all know that when you install the latest versions of software, it usually slows your computer down. Now on to the meat.

One thing is because programmers are lazy, and if their code runs slow they assume the user will just get a faster machine.

Well, are you a developer? If so, then you know what you say isn't true. If you arn't a developer, you must not know many of them. Users literally scream for new features, and the developer has to implement them, and FAST. It's not laziness as you should well know, it's priorities. Most users would rather a burgeoning web browser support cookies, rather than run 10% faster. Just go ahead and ask any user(who knows what cookies are), and they'll agree.

The fact is, that you're partially right. A hundred new features shouldn't significantly slow down a program if those features are not used. However, it WILL take up more space on your hard drive - there is absolutely no way around it, short of having a CD custom-made with the software compiled to exactly your specifications.

Now, unless you're going to go around to software projects and modularize their code(which was probably never meant to be modularized in the first place), I suggest you speak better of programmers. Especially Open Source/Free Software programmers who have graciously donated their time and effort to bring you, the ever so poor end user, a usable product.

Dave


Barclay family motto:
Aut agere aut mori.
(Either action or death.)

I hope you're right...

[driehuis]

Mozilla is, in a way, a very succesful open source project, which attracted lots of really talented outside contributors. And indeed, a lot of attention is being paid to reducing bloat at the moment.

Unfortunately, a number of design decisions were errrr less than optimal. The XUL user interface language seems to have a big impact on performance. And leaving aside whether one likes the UI or not, the fact that it behaves different than other apps on any given platform also leaves a lot to be desired (to Mozilla's defense, both Microsoft and Apple have gone down the tubes in this area as well, for example, I'm abhorred by Windows 2000's "browser like" clicking, where a single click will open a file rather than selecting it, and it isn't particularly obvious when it behaves the old way or the new).

Anyway, to be able to fix something in Mozilla requires a significant investment of time on the part of the contributor. In the first Mozilla releases, which were based on the 4.x user interface, I could usually locate something I want to fix in an acceptable amount of time. Now, with the overhaul and the complete switch to C++, I spend hours grovelling through the thing, usually without coming up with an answer.

So, open source or not, Mozilla's improvement still hinges in great part on the full time developers, who live and breath that code base. For me, and I think for a lot of other contributors, it has just become too complex.

I have high hopes for its evolution over time, but it won't be soon that it will be as fast as 4.x. It will be interesting to see how spinoffs like Galeon will handle leveraging functionality from Mozilla. Time will tell whether XUL will become a boon to browser extension development, or remain a drag on the UI performance...

Re:NS6 Plugin problems

[ucblockhead]

Netscape dropped LiveConnect, which is the way Netscape plugins comminicated with Javascript. They say that old plugins that require LiveConnect will "fail silently". They are correct, assumming that your definition of "fail silently" under Windows NT is "attempt to access a NULL pointer and crash the application".

They have a replacement for LiveConnect. It is almost completely undocumented. There is no SDK.

Geez, if I were a plugin developer, I'd be way pissed, and would hesitate to bother supporting Netscape 6.

Oh wait, I am a plugin developer.