[Captivate Android Development] CaptainTaco:
Just a quick statement/question, I work more on the Droid Incredible than the Captivate (Until Verizon releases the Fascinate... I.E. never). However, If anyone is have space issues, a small and quick workaround and compromise should be fairly easy.

At the sake of running most of your apps through the NAND, you could symlink your most spacious apps back to /data, and have them run via the old performance. So basically take specific apps like Google Maps, and FeedR, or any apps that have large data requirements, and you find you can compromise on speed for, and move those back to /data, in a folder such as /data/data2. Can't exactly give it a shot, as I don't have a Captivate on hand (my girlfriend is the owner of that device, and not around at the moment) but it may work, and give you a little extra space if you are out.

Example: (after original method has been applied)

Replace "DataFile" with App Data name, so for google maps "com.google.android.apps.maps"

mkdir /data/data2
mv /dbdata/data/DataFile /data/data2/DataFile
ln -s /data/data2/DataFile /dbdata/data/DataFile

A bit of a pain, but at least you wouldn't have to give up the entire lag fix if you reached your space limit... This would only work assuming /data is mounted to internal memory, which I believe is the case, but again not sure as I don't have the phone on me to check...

EDIT:

Also, I noticed these other methods of "fixing the lag issues" on devices such as the I9000 seem to use a method (also mentioned in this thread) involving partitioning an ext3 or ext4 filesystem onto the sdcard and using that as the /data/data mount point... I'm just curious if I'm the only one that finds that to be counter productive? While at the same time causing falsified benchmarks? Correct me if I'm wrong... but here's how this would theoretically work, A.) the speed of a microSD card would likely be slower than the internal memory already provided, however, formatting such a card with an an ext4 file system would effectively trick benchmarks into giving you a significantly higher score in that it will cache all of the tests run in RAM at which point the data will be journaled and eventually written to the SDcard. The benchmark will think the write was amazingly fast because what it thought was being written to the /data/data partition was actually just being written to RAM, only to then be written to the SDcard at the appropriate rate. While in the real world, when you have several applications running, already taking up RAM, and try to run an app that is going to write more than can be cached in RAM, that slow writing to the SDcard is going to become apparent in the opening of applications, etc., aka, quick benchmarks, no increase in performance in real world navigation of your phone and app responsiveness.

Am I way off here...? Basing this off what I know of the ext4 file system and how it works. The only thing that would make me doubt my conclusion, other than a better conclusion, would be if the bus speed of the SDcard was somehow quicker than that of the internal memory card, which I find to be highly unlikely. The only true fix for speed in my opinion would be to use the NAND memory as stated here. But,perhaps the people coming up with the other lag fix know something I don't.