So, I was futzing around with the site today and wanted to try out a forum plug-in and a poll plug-in. Forgot to back up beforehand.

Didn't like them, removed them. Then this evening went in to do my manual biweekly backup (I created the database outside of the cPanel structure long ago, so cPanel doesn't include it in the nightly backup), saw some tables related to the poll plugin, marked them, then hit the "drop" command.

Only I hit the one to drop the whole database, not just the marked tables. Clicked yes to the "are you sure" warning, because I thought it was just dropping those tables, then found out I'd dropped the whole database.

MySQL apparently doesn't have a "holy crap" button to immediately undo disastrous mistakes, and in all this time, really doesn't have a method to undo a database drop. You might possibly reconstruct it, but in general you're stuck restoring the database from backups.

Luckily I back up regularly, because I'm relatively paranoid. I lost a few edits to later chapters in the novels. More saddening is that I lost a number of comments posted in the last few days by friends and new readers including a discussion on the use of racially charged language in the early chapters.

So, for those of you who manage your own server... back up, back up, back up, and pay attention to those warning messages. We've gotten so used to them we mindlessly click. But if I'd read the warning message, I'd have known that I was about to kill much more data than I thought and could have stopped before it was too late.

And to those of you who posted comments in the last few days... SOOOORRRRYYYY! Won't happen again.

If you use the mobile browser detection script (this is a techy script for web developers who want to know if a page's visitor is using a phone/PDA browser or a "real" one), I've recently posted an update to it to accomodate the combo of IE8 on Vista and some software from Creative with an auto update feature. One of the substrings it looks for in the "user agent" string is "pda". You'll find that in the word "update". I've added an exception for that. I may need to visit that script in the new year, test it against the latest WURFL, and do some overhauling.

This evening, I went to my "My Yahoo" page, a customizeable personal page you can populate with news wire feeds, RSS feeds, and other Yahoo content. And it had gone back in time.

Note how all all the stories are "one week ago". Normally this feed is somewhere between a few minutes to "one day" ago. And the "one week ago" is inaccurate since most of the stories are dated between February 9th to February 11th. The same went for the comics farther down the page (Feb 11th). The segments that related to offsite RSS feeds were current, but any feeds created/licensed by Yahoo were reaching WAAAAY back.

Wonder how long it will take to fix. Oh, it's fixed. Well, at least it lasted long enough to grab a picture.

So, I was working on a project that generates a form based on a selection of items from a database, and the form could get pretty long. For performance testing I timed the execution of the script and found some very odd results. If the number of items on the list was 16 or thereabouts, the execution was about 5-7 one-thousands of a second. If the number of the items on the list was 50 (the maximum displayed on a page), the execution time was around 100 times longer.

I was stumped, how did increasing the number of items in the list by a factor of around 3 increase the execution time by a factor of 100?

I initially thought it was the database query. If the list was 16 items, that was the maximum number returned for the query. If the list was 50 items, it might have been the first 50 out of 300, which required extra sorting and organizing. But the database queries were timing out at close to the same speed.

I checked the processing of the data. Perhaps there was some bottleneck in my code that I could isolate. But as I broke the script down into smaller and smaller pieces, I found that all the parts that created the dynamically generated page were working fine up until I echoed the string that sent the compiled page to the user...

echo $page;

It was that line that took a couple of thousandths of a second when there were 16 questions, but took two or three hundred times longer when you tripled the length of $page. In fact, the tipping point was really between 19 and 20 questions. At 19 questions, it was executing in around 0.0085 seconds. At 20 questions, the execution time jumped to 0.27 seconds. Adding just one question caused the script to take 30 times longer to execute.

I Googled the topic and found that this is a well-known weakness of PHP. And, as a matter of fact, output in general is a weakness of PHP, because even knowing about this, people have long argued about whether it's faster to use "print" or "echo".

There were a number of suggestions on how to compensate, such as ob_start() and ob_flush to use output buffering with more fine grained control, but that wasn't doing the trick for me. Another suggested breaking the output string into chunks and outputting them individually in sequence. That also didn't work... at least not with his value of 8192 (8 kilobytes) as a chunk size. So I tried larger chunks (48 kilobytes, since that seemed to be the upper limit before slowing occurred) and smaller chunks (256 bytes, getting real small), but those weren't working. I was about ready to give up when I decided on one more try. I tried 2048 (2 kilobytes) and things finally sped up, and it seemed the best speed came from a 1-kilobyte chunk size.

So, if you find a PHP script is running really slow, the culprit might be something as simple as "echo $string" and the only way to fix it is to performance tune the output of that string. Amazing, huh?