Tl;dr: Passing in ‘true’ to item.Editing.EndEdit will prevent indexing and on:saving events during programmatic editing.
Patching in to the item saving pipelines in Sitecore is a very useful and powerful way to make automated changes to Sitecore items that I’ve used for various purposes since I started working with Sitecore. My current project has a LOT of item:saving events, which you can read about the reason for here. However, you need to be careful with customizing the saving pipelines, because it can have a significant impact on CM performance.
I recently added a custom processor to the item:saved pipeline. Why did I add it to item:saved instead of to item:saving? The reason is because I was trying to compare the current value of a field to the value it is supposed to be, but until the item:saving event is completed, accessing the field value was showing me the old value prior to editing. You can set the values of fields in item:saving, but trying to check the current/updated value won’t necessarily give you the right data during the saving pipeline. For that reason I hooked into the item:saved pipeline instead.
The issue is that in the item:saving pipeline you can directly edit the saving item from the args because it’s already in editing mode, but in the item:saved pipeline, you have to put it back in editing with item.Editing.BeginEdit() and item.Editing.EndEdit(). Remember how I said we have a LOT of saving events? This put a huge strain on the site, because now the saving events for each item were doubled (triggered once on save, and again after the item:saved processor); and in addition to that, our processor needed to conditionally edit other items as well, so now for every one item edited and saved by an author, it triggered the saving events for anywhere from 2 to 30 or more items. It worked fine on our lower enviroments, but when deployed to production with many content authors working at the same time, it killed performance.
(Side note: my code is probably a perfect example of why Sitecore wants us to stop customizing the pipelines and would give their devs a massive headache; but then again, if GraphQL returned items in the correct order, I wouldn’t have had to mess around with the pipelines – this issue should now be resolved in newer version but we are not on XM Cloud and I had to come up with my own solution).
Because of this issue, I discovered a very simple solution to fix the performance that I never knew about before: silent item editing. Passing in “true” to item.Editing.EndEdit (e.g. item.Editing.EndEdit(true)) will prevent further indexing and save actions on the item from being triggered by EndEdit(). Because this is an optional parameter, it is not obvious that you can do this. This provides a way to make programmatic changes to Sitecore items post editing without impacting performance (as much – the processor itself still has an impact on performance). Keep in mind though that you cannot not do this if your changes should trigger the save actions/reindex the item. Silent saving can lead to unexpected behavior and should be used with caution, because you’re deliberately preventing pipelines from running – only use it if you know why you’re doing so. One side effect of silent editing is that the changes made to the fields may not be visible to the content authors right away, as a result of the item not being reindexed. This is not a problem for us because the content authors do not need to be concerned with the sort order field and shouldn’t be editing it anyway, but it’s a side effect to be aware of.
Erica's Sitecore Adventures 