Keith Devens .com |
Friday, December 5, 2008 | ![]() |
| And if you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't... – Joel Spolsky | ||
|
| ← techInterview is awesome | RSS 2.0 → |

Simon Willison (http://simon.incutio.com/) wrote:
Keith (http://www.keithdevens.com/) wrote:
I actually just benchmarked it and my code is pretty fast. It parses a recent version of my configuration file in an average of about .0081 +-.0002 seconds. But if I wait so that the file itself isn't cached in RAM anymore, it shoots up a bit. Reading the disk is definitely a large portion of the execution time. I haven't tried MySQL, but I can't imagine it being faster than the plain filesystem, though I've never tried it either. One thing that might be faster, like you said, would be to use a PHP serialized version of the data, since I assume the parsing routines for that are in C. I wish PHP had better profiling features 
Capz (http://capzilla.net/) wrote:
You could create a ramdisk partition, and store the file there (and copy it on bootup before the webserver starts). That should work. ;-)
Keith (http://www.keithdevens.com/) wrote:
That's probably what I'd do if I had full control over the server.
Unfortunately, I'm on shared hosting.
Simon, if you don't mind, I'd be real interested to know what you store in your XML files. You don't have to get too specific, of course, I'm just interested in what type of information you put there.
Capz (http://capzilla.net/) wrote:
Hm, you're making an optimization for something that takes less than a millisecond? I'm sure there are better areas to optimize.
My site uses automatic keywords, so for every article the keyword database was searched for each topic. A typical search took ~65ms, the main page took ~253ms. I now create a cache of topic search results first, bringing down those times to ~39ms and ~52ms, reducing the number of searches and SQL queries dramatically. Now that's performance improvement!
I should be able to get that down even further by keeping that cache in a database, refreshing it only when posts change or are added.
On a server with decent RAM, you should not need to worry about loading files.. that has been probably been optimized already within PHP, the webserver and the OS kernel anyway.
In fact, storing the data in RAM actually should not help at all. If it needs to load the file from disk, because the contents were swapped out, there's an equal chance your custom RAM storage would be swapped out as well. Swapped memory is probably slightly faster than a disk access elsewhere, but I wouldn't really expect that to be much of an performance difference. Using an explicit ramdisk would probably prevent data from swapping out though, but if that's not an option..
I would start to look for other optimizations.
Rob
Capz (http://capzilla.net/) wrote:
Oops, make thay ~36ms and ~46ms now that my engine caches Authors it looks up from the dbase.
Feel free to post a comment below. Please see my comment policy.
Formatting Rules (No HTML):
Generated in about 0.229s.
(Used 8 db queries)

I've never tried anything like that, but I'm pretty sure the shared memory extensions (or something like that that has to be compiled in) are the only options. If most of the work done by the configuration code is in parsing the config file in to a data structure you could try caching a serialized version of that data structure in a file. Alternatively, could storing it in a mySQL table be faster? (I've never benchmarked mySQL record access against filesystem access so I don't know). Either way, if you're just after a performance increase your best bet would probably be to try serializing objects on the filesystem and in a database and then benchmark to see which is most effective.
That said, remember PHP is outstandingly fast at pretty much everything. My blog pulls in data from a bunch of XML files, loads about 15 classes and does a whole bunch of SQL queries for every page load and still generates pages in a fraction of a second.