$__reset method is slow on document with large number of subdocuments

[alexd6631]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the performance issue has not already been reported

Last performant version

6.9.2

Slowed down in version

6.9.2

Node.js version

18

🦥 Performance issue

Context :
I had an issue at work when saving a document with a large number of subdocuments.
The mongoose model (written with Typegoose) use a Map to store unique pair of keys and sub-documents, in a single mongo document.

When adding a set of keys, to a document having already thousand of keys, I noticed the .save() was quite long, at first I suspected that the change detection or write to the db itself was the most expensive. But a profiling session showed that the bottleneck was on __reset method calling isModified.

I also noticed the problem was aggregated by the size of the batch of new keys added to the inner Map.

After stepping into the save/reset/isModified methods using a debugger I noticed the following :

• $__reset iterates through all the subdocuments
  

  mongoose/lib/document.js

  Line 3277 in 7971a4d

  for (const subdoc of subdocs) {

• For each sub-document, we iterate on the modified paths :

  mongoose/lib/document.js

  Line 2198 in 7971a4d

  return directModifiedPaths.some(function(mod) {

So the reset method seems to operate in O(n_subdocs * n_modified_subdocs), which seems the biggest culprit here.

As a workaround, since I am not modifying the object after save() (and I no longer use the object), replacing .save() by model.updateOne(model.getChanges()) yields a large performance improvement (my bench goes from 45s to 1s)

Steps to Reproduce

Unfortunately I can't share the benchmarking code as is.
Having a document with a large set of subdocument (for instance in the map), and trying to modify/add new subdocuments by batch should be enough to reproduce the problem.

Expected Behavior

$__reset should probably not a bottleneck when saving a document.

[alexd6631]

After second look, it seems to be similar of : #13191
I am keeping the issue open, since the profile flame-graph and pre-analysis done here, could help fix the issue.