I went price digging today for an additional gigabyte of RAM for my MacBook Pro and found some irritating pricing information I thought I'd share.

Crucial is easily my place-of-choice to purchase memory, so I naturally looked there first. At crucial, you select your manufacturer, make and model and they should you compatible upgrades. Here's what I found:

• MacBook Pro 2.16 Ghz 17": $201.39
• MacBook Pro 2.16 Ghz 15": $184.29
• MacBook Pro 2.0 Ghz 15": $189.82
• MacBook Pro 1.83 Ghz 15: $165.86 (on sale)
• MacBook Pro 1.67 Ghz 15: $165.86 (on sale)

So while you might assume that the different prices are a result of different part numbers representing different memory modules with distinct specifications, you'd be wrong. Each of the memory modules represented above has the following specs:

• DDR2 PC2-5300
• CL=5
• UNBUFFERED
• NON-ECC
• DDR2-667
• 1.8V
• 128Meg x 64

So what gives? Why is it that crucial feels the need to keep distinct part numbers on file for something that is clearly not a distinct unit? And why price them all variably? I find this very frustrating. Needless to say if you go Crucial, get the 1.67 Ghz upgrade and expect to work flawlessly in my 2.0 Ghz model for less.

Crucial, while great, doesn't have the best prices though.

NewEgg sells the same crucial memory for $ 149.00, and has other non-name-brand modules for as low as $79.00!

Ramjet prices their upgrade module at $135.00, while Other World Computing ranks the best coming in at $112.00

Apple by the way, prices a similarly spec'd memory module at $300.00 even.

A colleague of mine at Zedak recently sent out an email directing our attention to Prevayler - a rediculously fast persistence layer for Plain Old Java Objects.

Boasting speeds 9000 times faster than Oracle and 3000 times faster than MySQL (when queried via JDBC), and licensed under the LGPL, one might ask why everyone hasn't already switched. The answer is simple, scary, and potentially complex: it stores the whole of your data model in RAM, so it's readily accessible at lightening speed. The concerns are obvious, and the answers simple.

Prevayler persists snapshots of the memory image to disk regularly (you can configure the schedule) to ensure long term persistence, and keeps a persistent log of issued commands in the event of a crash - similar to a journaling file system. The idea is that's its faster to write down what you asked for than to read the information you need; if you already know the answer, why go to the book, right?

The driving motivation behind Prevayler is that RAM is dirt cheap - much more so than physical storage. Of course it's not without its limitations; today's 64 bit processors can only handle 8 gigs of memory, and the vast majority of us are still on 32 bit hardware handling at most 4 gigs. Whereas one can store countless terrabytes of data on other mediums such as hard disks and DVDs - and lets face it, sometimes you just have more than 8 gigabytes of data; although for me and my friends Tom, Dick and Harry Web Developer, 8 gigs is a relatively unrealistic amount of information.

It's limitations and unrealistic applications are pretty well documented by Prevayler's authors though; they're even good enough sports as to post emails from uninterested traditional RDMBSers accusing them of being zealots.

Personally, I think it's a great idea. I saw mention of cross-language support on their site; perhaps I'll look into it for Blosxonomy caching. It'd be great if I could keep the Blosxom like file-system entries and use an in-memory DB like cache - my performance would sky rocket! It would also be a great segway into developing a full-on SQL based Blosxonomy entry locator.