A few days back, I worked on an situation where a POPULATION job was taken around 7-10 seconds per CI, on a real life situations where there can be thousands of Cis, this can make this job a time demanding action taking often hours or evens several days to do a full sync.
Since we are dealing with a POPULATION job, we could avoid some actions in SM that consumes most time. In our case, most of the time was being spent when validating the cascade updates, OOB it will perform queries on contractitem, SYSATTACHMENTS, two on cirelationships (one looking for parents, other for childs) and cigroup.
Usually, for SM normal operations these cascade updates are useful to maintain data integrity, however on a POPULATION job this is not likely to be used.
The reason these are called by on a POPULATION job is because once a new CI is inserted in uCMDB from SM, the CMDB engine will execute a push back update action to fill the new ucmdb.id field on the device, however this request (UpdateucmdbIDPushBackRequest) will only modify this field, so in theory no other action will ever take place and the cascade updates will never update related records, however they WILL perform the query adding valued seconds to the processing.
This can be easily bypass if we use a condition on the cascadeupdate record using the integration operator (in the example is falcon).
You could eventually create a different cascade update record and match the conditions so that only the custom one will execute on the integration jobs.
After doing this change, we notice that each CI went from taking 6-10 seconds to process around 20 per second.