function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Time Between DML Statement and Before Trigger

Hi all,


I am trying to optimize some code which takes a while to run.


First I wrapped a DML statement in the following to get the time of execution:


Long start = System.currentTimeMillis();
update something;
Long diff = System.currentTimeMillis() - start;

 Results show an execution time of about 2 seconds.  So I drilled in deeper and wrapped the triggers in the same code and found that the triggers execute in about 200 milliseconds.


I verified there are no workflows firing and at this point and am starting to scratch my head.


So I took it another step further and take the time before the dml update statement, and then take the time as the first line of the before trigger...and lo and behold salesforce is spinning its wheels for 2 seconds.


Next I looked at the Triggers and Order of Execution entry in the Apex Developers guide, the only things that happen are:


On the server, Salesforce:

  1. Loads the original record from the database or initializes the record for an upsert statement.
  2. Loads the new record field values from the request and overwrites the old values. If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
    • Compliance with layout-specific rules
    • Required values at the layout level and field-definition level
    • Valid field formats
    • Maximum field length
    Salesforce does not perform system validation in this step when the request comes from other sources, such as an Apex application or a Web services API call.
  3. Executes all before triggers.

What this says to me is that for 1 record (my dml operation is only updating a single record) its taking force 2 seconds to do steps 1 & 2.  This is really only an issue with this sObject.  Other sObjects with more complicated triggers take less execution time.  I am thinking this 2 seconds is due to there being ~100 formula fields on the sObject I am updating, and force needs to perform a query on all fields on the sObject as apart of step 1.  Can some SFDC mastermind confirm my findings?  Is there anything I can do or is this the cost of developing on the platform?





It sounds like your analysis is roughly accurate.  I wouldn't characterize it as "the cost of developing on the platform".  I'd call it "the cost of developing something extremely complicated", as 100+ formula fields on an object will take a while to calculate, regardless of what platform you're building on.


I guess the real problem here is that SFDC must do something funky to initialize the trigger when there are so many fields that it cant grab them all in one go, cause its hits the 64k oracle query size limit.


Could a moderator or someone from salesforce comment on this?




I work for salesforce.  If you think there's a performance issue on our side, please log a case with the relevant details.


I'm content with your answer dkador, thanks for your help.