Recently I spent several hours chasing 280 milliseconds that I was convinced should not have been there.  The ServiceAPI URL I was calling looked like this:

http://localhost/ServiceAPI/Record?q=container:9000002536&format=json&excludecount=false&pagesize=100&properties=recordtitle,recordowner,recordcontainer,recorddateregistered,recordassignee,recorddatecreated,recordcreator,recordnumber

After hours tuning the ServiceAPI code I managed to tweak a 20 millisecond improvement, still I was sure there was more. I looked once more at the URL and made one small improvement, to this:

http://localhost/ServiceAPI/Record?q=container:9000002536&format=json&excludecount=false&pagesize=100&properties=recordtitle,recordownerlocation,recordcontainer,recorddateregistered,recordassignee,recorddatecreated,recordcreator,recordnumber

Suddenly I had eliminated my extra 260 milliseconds!

Can you spot the difference?  Previously I had an incorrect property name, RecordOwner should have been RecordOwnerLocation. Why is this a problem? If the ServiceAPI does not recognise a property it checks to see if it is a valid 'additional field' for this Record.  Multiply the time to check this by 100 (the page size) and there is the 260 milliseconds.

The moral

260 milliseconds is not a lot but in a web service environment it adds up so be careful to to include invalid property names in the properties parameter.

Now I am off to see if the 'additional field' code can be optimised.