vtable caching

Open
#807 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
cpp, csharp
Domain
performance, tooling

Research direction

Start at src/Generator/Generators/CSharp/CSharpSources.cs around line 2425 and review how pure virtual wrapper calls calculate the slot pointer and create delegates. Determine the intended caching lifetime and whether the existing behavior should remain optional or become the default; done requires an agreed caching design and corresponding implementation.

Written by the indexing model from the issue text.

Description

enhancement

When generating managed wrappers for pure virtual functions the generated code ALWAYS "calculated" the pointer for the slot and generates a delegate wrapper (using Marshal.GetDelegateForFunctionPointer) for every single call... (in CSharpSources.cs)

Unless I'm completely out of my depth, this is a rather expensive call that could/should be cached when the wrapper object is new'd up...

Is there a reason for this weird behavior?

Would a pull request adding a caching layer be welcomed?

If so, should the existing behavior be made optional? default?

I would appreciate any sort of feedback, esp. a one explaining to me if/how I'm not grasping the situation...

Dominant language
C#
Stars
3.4k
Forks
541
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mono/CppSharp

All issues in mono/CppSharp

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.