Managing our own performance can be powerful and will be better than someone else doing it.
My first xquery experience has been on the MarkLogic platform. The project that we just released was written entirely in xquery and on that platform. As our site continues to gains popularity, we continue to realize how little about xquery we knew or know. Sometimes and in some places, the site is just really not that performant. “But I thought MarkLogic/xquery is super-scalable,” some exclaim indignantly. If you do it right, an Oracle relational database can be made to scale. Done wrong, a MarkLogic database can be made to not scale at all. There’s a lot to be said about knowledge of the platform, the language, and how to wrestle it to do your bidding. Here are a few optimization ditties that I’ve collected as of late that might help in your future xquery dev.
I was running an SQL query today and it was sooooo slow. So slow, in fact, that it never returned. I asked the DBA, Reed, who built the table what might be up, and he informed me that it was not indexed. And proceeded to show me some cool stuff I could do to actually get my query to return. In the end, it was a comparison between the “not in” operator and a “left join”.
Often when coding, we use a single local variable multiple times, overwriting the value many times. It is considered good practice to move the variable out of the looping overwrite and into the smallest scope of code that is run once. But, this makes the code a little bit less concise. So, how useful is it, anyway? I wanted to run a few little tests and see if there’s really a noticable difference in performance.