> Even faster would be to write your code in assembly, and dump that > ridiculously bloated database and just write everything to raw bytes on > an unformatted disk. Of course, it might take the programmer a thousand > times longer to actually write the program, and there will probably be > hundreds of bugs in it, but the important thing is that you'll save three > or four milliseconds at runtime.
> Right? Correct. I didn't quite see the issue as assembly vs. python, having direct translation to programming hours. The structure in mind is meant to act as a dictionary to extend my db with a few table fields that could vary from one record to another and won't be queried for. Considering everytime my record is loaded, it pickle or marshal data has to be decoded, I figured the faster alternative should be better. With the incompatibility issue, I figured the day I upgrade my python, I would write a python script to upgrade the data. I take my word back. > Your database either can handle binary data, or it can't. It can. It's my web framework that doesn't. > If it can, then just use pickle with a binary protocol and be done with it. That I will do. > Either way, you have to find a way to translate your Python data > structures into something that you can feed to the database. Your database > can't automatically suck data structures out of Python's working memory! > So why re-invent the wheel? marshal is not recommended, but if you can > live with the limitations of marshal then it might do the job. But trying > to optimise code that hasn't even been written yet is a sure way to > trouble. Thanks. Will do. Regards, Mike -- http://mail.python.org/mailman/listinfo/python-list
