Wednesday, May 30, 2012

Firefox Performance Problems

Lately I've noticed Firefox seems to be lagging as of the latest release of version 12. 

Since my earlier post regarding setting Firefox up to utilize CPU affinity in Windows, things have been manageable, but lately a familiar flavor of failure seems to have crept back into this latest release.

If I leave Firefox open and running overnight with my usual group of a dozen or so tabs open, as soon as I resume activity in the morning, I notice in Task Manager that Firefox has one of my system's CPU cores at 100% usage, and has well over 1.7 GB of system memory in use, far more than what typically ranges from 400 to 700 MB on an average day.

Any given morning, thanks to Firefox.

More often than not, once I clear this CPU usage spike by ending the firefox.exe process, when I reopen Firefox I'm greeted with tabs notifying me of add-on updates that have been applied. 


This same issue seemed to be absent as of, say, version 10, but appears to have recently reemerged, at least in my experience on several different PCs running Windows 7.

A common thread among established users on the Firefox support forum points to the various add-ons users have installed. Clearly, many of them say, this is the culprit, and the often the user is advised to open Firefox sans add-ons and attempt to reproduce the problem by enabling add-ons one by one and testing after each to determine which might be the culprit.

I have no desire to invest the time and effort in something that I think developers and analysts at Mozilla should be hammering out themselves. It seems that if you release a platform on which users will develop add-ons, there should be safeguards in place to prevent poor coding from disrupting the integrity of the browser's functionality.

That being said, if you have a 64-bit system, consider trying out Waterfox, a Firefox build which emphasizes performance and speed, and mitigates a lot of whatever lurks in Firefox's codebase that might be causing this excessive memory usage and lag.

Perhaps it's some insidious conspiracy to make it so that when your computer is otherwise asleep at night, Firefox will rear its head and ramp up CPU usage and therefore power consumption, making an impact, however small, on world oil prices, driving up costs and compelling people to bite the bullet and get off the grid with their own solar, wind, nuclear, or other alternative power source.

I've had crazier ideas!




Saturday, May 12, 2012

Magnets, How They DO Work

Love bug season has descended unexpectedly early here in north central Florida.

Love bugs love lovin' at our expense.
 
Swarms of these annoying insects, male and female joined at the butt, fly adrift, ready albeit unwilling to let themselves be splattered at high speed against the finish of your car. Given time and accelerated by summer heat, their acidic gut chemistry can pit the paint and fill the delicate fins of your radiator with bug parts.



An easy, somewhat ghetto measure can be taken to protect the radiator and engine compartment from these annoying insects. All you need is some plastic screening material, a dead hard drive, and scissors.

I drive a minivan, so I don't much care about its finish, I'm more concerned about function than form. In my case, I just cut a swatch of plastic screening material large enough to cover the radiator openings in the front grille, then secured it at either top corner with a rare-earth magnet salvaged from a long-dead hard drive.



The few inches of overlap will allow the screen to stay draped over the grille openings while driving, as will the curve of the grille itself. A masochist might go so far as to have a wire mesh complete with some power running through it to act as a mobile bug zapper and decrease the bug population, but I lack the motivation and time to go that far, I'm content to just keep them out.

Now my engine can remain bug free, without compromising airflow the engine needs so that the radiator can dissipate heat on the road.


Friday, May 11, 2012

Inconsistent Line Ending Style

In trying to commit some changes to SVN using the TortoiseSVN client, I received an odd error for a single SQL database table script text file:

Inconsistent line ending style


On the TortoiseSVN forums someone suggested that this might have occurred because someone edited the file in multiple editors, and somewhere in the process happened to slip in a line feed particular to their editor which version 1.7.4 of our Apache Subversion server found disagreeable.

To work around this, I was able to open the file in Microsoft Word, then save the file as plain text, with Windows (Default) chosen for text encoding:



Why SVN server scrutinizes the line feeds is unclear to me, but thankfully whomever committed the offending change made it to just this one file out of hundreds in the repository.