SF-PD2 Performance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Database.update with the allOrNone parameter set to false.

  Why it's wrong here

  Setting allOrNone to false allows partial success, which is useful for error handling but does not improve performance. It still processes each record individually if called in a loop. Bulkifying DML is about grouping operations into a single call, not about the allOrNone parameter. This option does not address the inefficiency of per-record DML.

• ✗

  Use the insert method instead of update to avoid conflicts.

  Why it's wrong here

  Switching from update to insert changes the operation but does not reduce the number of DML statements. If the records already exist, insert would fail. The performance issue is the loop causing multiple DML calls, not the type of DML. Bulkifying is the correct approach regardless of whether you are inserting, updating, or deleting.

• ✓

  Use a Map to deduplicate records before performing DML.

  Why this is correct

  Deduplicating records with a Map ensures that each record is processed only once, reducing the number of DML operations and avoiding errors like duplicate updates. This is especially important when the same record might be updated multiple times in a loop. Combining deduplication with bulk DML further optimizes performance by minimizing the data processed.

• ✓

  Collect records into a list and perform a single DML operation outside the loop.

  Why this is correct

  Bulkifying DML by collecting records into a list and performing one DML call drastically reduces the number of database operations. Salesforce governor limits allow only 150 DML statements per transaction, so per-record DML quickly hits limits. A single DML on a list of records is much more efficient and is a fundamental best practice for Apex performance.

• ✗

  Use the @future annotation to perform DML asynchronously.

  Why it's wrong here

  @future methods are for asynchronous processing and can help with callouts or mixed DML, but they do not improve DML performance. They still execute DML and have their own limits (e.g., 50,000 calls per day). Using @future for bulk DML would be inefficient and could hit callout limits. The core issue is the number of DML statements, not the synchronous execution.