The most likely cause isn’t .NET itself, but the way ODC is invoking your .NET library on each call.

In OutSystems Developer Cloud, every call from an action to a custom .NET library crosses a process boundary (OutSystems runtime → your library). If you call that library in a tight loop (100 times, 1000 times, …), you’re paying the overhead of:

• Parameter serialization / deserialization
• Context setup (per call)
• Inter‑process / inter‑service communication

Even if the method is trivial (returns a static string), that call overhead doesn’t disappear, so the per‑call cost dominates and you see the near‑linear scaling:

• ~10 calls → ~3s
• ~100 calls → ~30s

That pattern strongly suggests it’s not “slow .NET code”, but “expensive integration boundary”.

What you can do about it

1. Batch work in the .NET library instead of looping in OutSystems

   Instead of:

   For each item:
       Call MyDotNetLib.DummyMethod(Item)
   

   Refactor to:

   • Pass the whole list / structure from OutSystems into one .NET method.
   • Do the loop and processing inside .NET.
   • Return the combined result.

   That turns 100 slow calls into 1 call, where the overhead is paid only once.

2. Minimize data passed on each call

   If you must call the library multiple times:

   • Keep parameter sets as small as possible (especially large structures or lists).
   • Avoid passing big binaries or JSON blobs per call; if needed, compress or chunk them and still prefer batching.

3. Check for extra overhead in your implementation

   Inside your .NET method, confirm there’s no hidden cost per call, such as:

   • Creating heavy objects (e.g., HttpClient, DB connections) on every invocation.
   • Doing I/O (logging to disk, network calls, etc.) per call.
   • Using reflection, dynamic loading, or expensive configuration initialization each time.

   Move those to some sort of static / cached initialization if possible.

4. Consider OutSystems native alternatives

   For things OutSystems can handle natively (string manipulation, math, simple data shaping, HTTP calls, etc.), it’s usually faster and simpler to implement directly in ODC actions than jumping into a custom .NET library, especially in loops.

5. Measure per‑call cost

   Add timing inside the .NET method:

   var start = DateTime.UtcNow;
   // trivial work
   var end = DateTime.UtcNow;
   

   Compare:

   • Total time measured inside the library (should be near zero for a static string).
   • Total time measured on the OutSystems side for the same number of calls.

   If the library time is negligible and the OutSystems side is slow, that confirms the overhead is at the integration boundary, not in your .NET logic.

In summary: the slowness is almost certainly due to calling the .NET library many times from OutSystems, not the .NET runtime or your trivial method. Redesign to do more work per call (batching) and keep calls few and coarse‑grained; that’s the main way to bring total time down in ODC when using custom .NET libraries.