Please don't abuse c:count

The c:count=1 is a very useful Query Command, but it will cause your queries to run *much* slower as it has to fully complete the query across the entire collection.  Without this, the query can finish as soon as it has found as many objects as is necessary.

Putting c:count=1 on every query in production is a bad idea.  Using it while you are experimenting isn't bad.  Using it when you already know that the query will return a fixed number is even worse.

If you need to get the count, please use the count verb (replace get with count).

For many queries, this could mean the difference between a result that takes 4 seconds and one that takes 0.004 seconds to process.

-dan

 

Lets say I want to pull back the id of an item based on it's name.  If it returns a single item, I want to show it.  If it returns multiple items, I want to redirect to a list. 

Right now, I'm using c:count for this, testing to see if count > 1, and redirecting to the list if it is.

I'm guessing this would be done better by doing a c:limit=2 and then testing to see if returned > 1?

Got to admit, I hadn't considered that but I imagine it would be faster that way.

 

Yes, that would be faster.  You could even put the c:limit to be whatever your page can display before paging or scrolling.

The c:count=1 is appropriate for paging results, but you should only use it on the first "page" if possible.  You should never use it when you fully expect only a single result.

The situation I was seeing earlier today ended up being somewhat misleading.  The queries were not slow because of the c:count=1, but rather that the query was on an attribute that was not indexed.

In general, you should expect that queries will have a seconds attribute of less than 1 second.  If you are consistently seeing greater than 1 second (and certainly if you are seeing multiple seconds), you should examine your query with c:explain=1 or thinking about how you can break the query down into a smaller request.

-dan

 

In Rostermaster I'm only using c:count=1 when at configuration time the webmaster tries to determine his guildID that will be entered in the configuration.  The result came back within less than a second, but I'll revert it back to sending a separate count query for the next release.

 

Lantis...

I think that is a completely valid use of c:count=1.  I'm mostly concerned with repeating queries that are obviously going to be returning a single result.  I'm only asking that you don't blindly stick a c:count=1 on every query.

Dethdlr's suggestion is very clever, ask for more than 1 and then handle that case separately.

This is not a huge problem - I am trying to point out ways to get every ounce of performance from the API, though.

-dan

 

Gotcha.

I thought you meant it should be reserved for debugging - my bad.

Hey, I'm all for optimizing.  I just spent 3 hours trying to improve performance of my paperdoll fetch+crop+resize+send code.

(the conclusion isn't always what you'd expect - in this case, I got a major performance gain by reducing compression and increasing the image filesize...)

 

I'm just breaking all optimization guidelines and resizing the paperdoll in-browser.

 

That was my original plan, but since I'm also cropping all that extra space around it, I cannot predict what will be the final size of the cropped image, so the aspect ratio might become askew.  I'm rather pleased with my latest crop+resize function I must say.