Create benchmark for Core.RemoveObjectFromList() implementation

[jozefizso]

Implements #448

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: dbea2cffb4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jozefizso]

Benchmark concern: DictionaryCoreVariant and ConcurrentDictionaryCoreVariant use obj.GetHashCode() as the dictionary key. That is not equivalent to object identity and is not collision-safe. The comments mention an IntPtr key, but the benchmark is measuring hash-code lookup instead, so these results should not be used to justify a dictionary keyed this way.

[jozefizso]

Benchmark concern: MockCOMObject overrides Equals and GetHashCode, while the production COMObject / COMDynamicObject implementations use the base object behavior. That makes the hash-based variants operate under cleaner equality semantics than the real code path, so the benchmark should use production-equivalent reference identity before the results are considered representative.

[jozefizso]

Benchmark concern: the mixed-operation benchmark does not run equivalent workloads for all variants. The List case allows duplicate entries in addedObjects, while the hash/dictionary cases check Contains before adding to that tracking list. That changes both the number of tracked objects and the cost profile, so the mixed-operation results are not directly comparable.

[jozefizso]

Benchmark concern: MemoryBenchmark is described as measuring memory footprint, but the methods allocate the benchmark objects, the tracking List<ICOMObject>, and the collection variant inside the measured operation. Removed objects also remain referenced by the local objects list. This mostly measures allocation throughput for the benchmark scenario, not retained collection footprint after removals.

[jozefizso]

Benchmark concern: the benchmark currently mixes add cost and remove cost in the same measured method. If the goal is to evaluate RemoveObjectFromList, the variants should be populated in setup and the benchmark should isolate removal. Otherwise the results include construction, growth/resizing, and add-path behavior, which can obscure the removal crossover point.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e0820de55e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Key dictionary variants by the object, not its hash code

When two distinct COM wrappers return the same GetHashCode() value, this dictionary variant overwrites the first entry and later removes by hash alone; the concurrent variant uses the same pattern. GetHashCode() is not a unique key, and the real COMObject implementation delegates to base.GetHashCode() in Source/NetOffice/COMObject.cs, so collisions are possible even though MockCOMObject makes them unlikely. This makes the benchmark compare a collection that can drop proxies under collision inputs rather than preserving the current list semantics.

Useful? React with 👍 / 👎.