Comments for Intrepid Blog

Comment on Parsing $_SERVER[’PATH_INFO’] by Anonymous

Anonymous — Tue, 13 May 2008 10:01:06 +0000

Useful!

Comment on Stupid PHP (1) (Strings are faster than Arrays) by brien

brien — Wed, 07 May 2008 21:48:19 +0000

hi, thanks for the benchmark, though I think it’s not in the spirit of php to have separate string implementations. e.g. array() is used to represent what should be two totally separate types of datastructs … though I suspect lists are just internally represented as hashes, which might explain their relatively poor performance here.

Anyway, I think you’d have to extend your test before you can make inferences about how php is allocating memory. e.g. store a ref to the intermediate value from each concatenation to make sure php isn’t counting pointers and toggling between immutable and mutable representations appropriately, etc.

Anyway, blah blah, thanks

Comment on Upgrading wordpress with git by Bas

Bas — Thu, 01 May 2008 22:22:38 +0000

You're probably right. Obviously you indeed want to check for stray files. Some might be usefull to keep around like uploaded images and alike. A look at git status is always helpful. If you want to clean untracked files from your repo then git clean (-f) is your friend.

Comment on Upgrading wordpress with git by Jonathan Addleman

Jonathan Addleman — Tue, 29 Apr 2008 22:20:18 +0000

I know this post is a little out of date now, but looks like it should still work with current versions of git and wordpress. One exception is that you’ll need to use “git checkout -b tmp HEAD^” instead of doing the checkout and the branch in two steps. I don’t know if that ever worked in two commands like you used there… It didn’t for me though!

The other issue I see is that if a new version of wordpress removed files that were present in the old version, the steps you describe won’t get rid of the old files. To prevent that, I think that deleting all the files before copying the new version into the tmp dir should work.

Comment on Benchmarking CouchDB (2) by Jeffrey Gelens

Jeffrey Gelens — Tue, 22 Apr 2008 22:51:35 +0000

Thanks for these great tests. I’m really curious about CouchDB’s read performance. Could you do also do such a test?

Comment on On the App Engine lock-in by Bas Westerbaan

Bas Westerbaan — Wed, 16 Apr 2008 07:08:16 +0000

CouchDB is not quite ready yet anytime soon. I’d place my bets on Hyper Table or Hadoop’s HBase which are explicitly modeled after Google’s Bigtable.

The hurdle with fetching pages and mail isn’t really that big: it’s not exactly what you do all the time you write an app. Bigtable isn’t that bad either, those unfashionable JOINS were going away anyway. And for the common case Django’s abstraction still works fine.

Though the limitations can indeed be a pain, it isn’t just the scaling that is cool about AppEngine. I think that Python will really get a boost as a web application development language. We’ll, no doubt, see a lot of new libraries and frameworks (all with AppEngine like restrictions in mind) written in Python, which is interesting.

Comment on On the App Engine lock-in by Jeffrey Gelens

Jeffrey Gelens — Wed, 16 Apr 2008 00:43:11 +0000

It is already running on Amazon EC2:
http://jchris.mfdz.com/code/2008/4/announcing_appdrop_com__host_go

Comment on On the App Engine lock-in by Zef

Zef — Tue, 15 Apr 2008 22:14:09 +0000

Mostly that won’t be a problem, the challenge would be BigTable, but I guess CouchDB could be used for that.

The question is, would this really be more interesting? I doubt it. People don’t use AppEngine because of it’s great APIs. Let’s face it, it’s more difficult to use than “normal” APIs like httplib, mail libraries and normal interfaces to relational databases. It’s its scalability that makes it interesting. Even if you would get the software from them, you would still need thousands of servers worldwide to scale like they do.

Comment on CouchDB document creation performance by Damien Katz

Damien Katz — Sun, 30 Mar 2008 00:24:02 +0000

Look at the CouchDB bulk save featues. With that you should be able create 1000s per second.

Comment on Stupid PHP (1) (Strings are faster than Arrays) by Bas Westerbaan

Bas Westerbaan — Mon, 17 Mar 2008 14:36:29 +0000

Actually, a JIT-ed javascript blows away PHP in performance. (Macromedia is working on getting a homemade JIT to replace spidermonkey in Firefox.) Also I consider Javascript to be one of the most underestimated languages there is. Obviously due to browser incompatibility and plain stupidity of browser designers, it can be a pain to work with at times, but the language itself is elegantly simple and certainly more powerful than PHP for algorithms.

That PHP is designed for internet scripting doesn’t excuse it for some of its stupidities. There is no reason not to include a StringBuilder. No reason to have a demented object model. Etcetera.

(But to be honoust. In most cases PHP does indeed get the job done quite easily and fast. It’s just that nagging. )