Tag: programming

Posted on
by

FirefoxOne of the biggest complaints about Firefox since 1.5 was released has been its high memory usage. Go to a forum anywhere and you’ll get people griping about “have they fixed the leak yet?”

It is, of course, much more complicated than that. There are caches, fragmentation, places where memory is used inefficiently, bunches of small leaks, leaks that only happen under specific circumstances, leaks in extensions, leaks triggered by combination of extensions, etc.—not one single leak that can be fixed. And then there was the unfortunate post in which one Mozilla developer (I’m too lazy to look up who) pointed out that 1.5 stored more information in memory, and that probably had a bigger impact on total memory size than actual leaks, which many people on the Internet jumped on as “It’s not a bug, it’s a feature.” (Why should they bother to read what was actually stated, when they can just read a misleading but sensational summary?)

A lot of the small leaks were patched in bugfix releases for 1.5 and 2.0, but really big changes are coming in Firefox 3. Mozilla’s Pavlov has written a detailed post on Firefox 3 Memory Usage, describing the different categories of memory improvements that have been made in the Firefox 3 development cycle.

I wouldn’t be surprised to find that this is one of the big reasons Firefox 3 has taken so much longer than previous releases. I suspect it’s time well spent, though, and users will be happier with a later, lighter Firefox than with one that shipped earlier, but used just as much memory.

Posted on
by

After updating some links, the following dialogue occurred to me:

Sallah: Indy, why does the web… move?
Indiana: Give me the URL.
(The location looks like a Python script)
Indiana: Snakes. Why did it have to be snakes?
Sallah. ASP. Very dangerous. You go first.

(Actually, I have to credit Katie for the Python reference. The first and last lines just popped into my head, though.)

Posted on
by

All the Linux desktop action these days is in KDE and GNOME, but on older hardware, servers, or anything else where you need to squeeze every last ounce of performance from the box, something lighter is needed.

[Screenshot of a WindowMaker desktop] My Linux box at work — a 300 MHz Pentium II — runs WindowMaker. It’s familiar, it stays out of the way, and it doesn’t tie up the memory or CPU that a modern version of KDE or Gnome (or Windows, for that matter) would. But you need to add applets like a clock or a desktop pager. You can find them easily enough — I ended up using the aptly-named wmclock and wmpager – but there’s a significant problem with both. WindowMaker lets you change the size of the dock icons, but when I shrank the dock to get more space I discovered that both applets have a hard-coded size of 64×64 pixels.

[Pair of WM Applets, first at default 64x64 size (they look fine), then at 48x48 (they don't adjust and edges get cut off)] As you can see, a 64×64 applet just doesn’t work in a 48×48 space. It surprised me, though, since these dockapps are designed specifically for WindowMaker, and it’s WindowMaker itself that lets you change the size. You open up Preferences, change the size, and restart WM. Just menus and buttons. No config files, no registry, no third-party add-on. This isn’t an esoteric hack that takes serious effort to find, it’s a basic feature. You might as well design a Mac program that assumes the Dock is on the bottom of the screen. For most people it will be, but it’s not rocket science to move it.

In my ICS classes, they always discouraged us from using “magic numbers” — just throwing a number in the code without identifying or abstracting it. There are two very good reasons for this. The first is that you might forget what this 64 is doing. The second is that you might decide to change it later on, and it’s much easier to change one SIZE=64 definition than to track down every 64 and hope you’ve neither missed any you need to change nor changed any you need to leave alone.

Those dock applets are stuck at 64×64 pixels because the programmers were thinking in terms of the pixel grid, not in terms of actual display size. Continue reading →