Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I observed that if i use Database.QueryLocator in batch start methond than the Iterable<sObject> i gets better performance. I could not figured out why?

In my case Iterable<sObject> taking around 18-20 seconds but if i use Database.QueryLocator than process gets completed within 5-6 seconds.

Can any one explains how does Database.QueryLocator works behind the scene?

share|improve this question

2 Answers 2

up vote 8 down vote accepted

I'm not a Salesforce developer, but this is my thoughts on this observation...

Serialising. The result set returned by the start method is likely serialised into the batch subsystem of the platform regardless of how its delivered. This thought is supported by the fact that the records subsequently passed back to the execute method are effectively stale. Meaning changes made to them since the job was started are not reflected.

Execution driven by De-Serialising. As such this observation leads me to consider that the platform serialises the result set regardless, and the job then becomes driven by the platform de-serialising the resultset according to the scope size applied to the job.

Serialisation Overheads vs Querying. While one might expect the serialisation stage to show some improvement for itterable, in theory since the database work has been performed outside of the job execution. This is likely to masked by the platform performance variance and the chunking behaviour of the job. So what i think your observing, giving the variance is not so great, is more than likely to be the usual fluctuations in the platforms performance with it being a shared service.

Further Profiling and Evidence to Present Salesforce Support? That said, if you are finding a pattern regardless of time of day and averaged over a series of tests, perhaps with a larger volume of data to stretch out a bigger consistent and observable variance? Then it may be worth seeing if you can get an explanation from Salesforce via a Support case, though I think its likely they will claim its a bug, you may get some useful further insight to share perhaps? :-)

Summary.

In summary i think what your seeing is a combination of two things. Firstly the natural platform performance variance (as the servers respond to different loads by its users, timings vary). Secondly the difference in serialisation times during preparation phase of the job.

Regardless QueryLocator or Iterater the serialisation needs to be done to start processing the items in the job. What you may find if you increase the number of the items, is the time taken to serialise goes up, this will be most apparent in the start phase of the job rather than the overall execution. Or stated another way, a variance in the start phase of the job for higher volumes is not that much of an issue vs the performance of your code in the execute phase.

Note: Serialisation is the process that takes your output from the 'start' method and stores them in the internal server store for processing as the job runs. De-serialisation is the reverse of this process, and is being done ahead of the 'execute' method being called.

share|improve this answer
    
Sorry but i could not get your answer. It would appreciate if you can simplify it. –  Pramod Kumar Dec 19 '13 at 12:44
    
Sure I've added a summary, which may help, basically its a bit of theory, since we don't have access to the internal code of the platform we don't know for sure, so wanted to show my thinking about as well as state what i think is going on. :-) –  Andrew Fawcett Dec 19 '13 at 12:59
    
Thanks a lot for your summery. –  Pramod Kumar Dec 19 '13 at 13:02

Database.QueryLocator is an abstract representation of a query. It does not actually contain SObjects. So between subsequent Batches, only the information on how to retrieve SObjects from the Database has to be passed around.

Using Iterable<sObject> on the other hand, you are passing around actual SObjects, which need to be serialized/deserialized and so on. This obviously takes much more time than just passing around an SOQL snippet. However, it opens up the possibility to run Batch jobs on entirely different Objects such as String or you name it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.