After this post was published, Brady Vercher also reminded me of two WordPress-specific functions.
When it comes to working with the WordPress database – or any application that provides an API for data serialization – I try to always stick with the API unless it’s absolutely unavoidable.
For the most part, I tend to favor APIs that provides the necessary functions for reading and writing data, and I generally assume that they have everything built into them that they need in order to make data storage and retrieval as secure and as fast as possible (though I’ve been burned by this assumption before).
In some cases, this is true; in others, not so much.
Case in point: I’ve been working on a large intranet application for someone that’s built on top of WordPress. One component of the application requires the import of a relatively large set of data in CSV format that’s also piped through a third-party plugin.
Unfortunately, there was a bottleneck in the code that was causing timeouts on the remote server.
- No matter how high you set PHP’s timeout settings, a third-party script monitor would always kill it first. I’m actually in favor of having these types of monitors running.
- Long scripts create a terrible user experience so I wasn’t happy with the performance even when I was able to marginally improve it.
- Isolating bottlenecks can be a tedious process, but can seriously pay off if you spend the time to do it.
When I finally located the bottleneck, it was occurring in the third-party plugin.
