[Controller] POC: overall speedup by fredroy · Pull Request #573 · sofa-framework/SofaPython3

fredroy · 2026-02-03T03:51:35Z

I did detect this issue some time ago, about having a controller in a scene was slowing down the simulation so much, especially on macOS. Even if the controller do nothing. And it gets slower and slower more there are Controllers.

DISCLAIMER: this was mostly the work of Claude, which detected/suggested the issues (lookups were slowing down the simulation) and generated the solution.
I just did the benches/tests to make sure it works, but as for everything with sofapython3 and/or pybind11, I cannot prove everything is okay/well-done. So deep review from experts would be appreciated 🫠

In any case, the modifications lead to a dramatic speed up:
(refer to the scene with this PR, which creates an empy scene with a certain number of Controller doing nothing)

Ubuntu 22.04 (gcc12, i7 13700k)

before:
Scene with 1 controllers and 10000 steps took 2.464146852493286 seconds.
Scene with 5 controllers and 10000 steps took 12.076464414596558 seconds.
Scene with 10 controllers and 10000 steps took 24.062500715255737 seconds.

after:
Scene with 1 controllers and 10000 steps took 0.04976940155029297 seconds.
Scene with 5 controllers and 10000 steps took 0.09446001052856445 seconds.
Scene with 10 controllers and 10000 steps took 0.1459205150604248 seconds.

--> with 10controllers, 150x faster... 😮

Windows (MSVC2026, i7 11800h)

before:
Scene with 1 controllers and 10000 steps took 6.102800607681274 seconds.
Scene with 5 controllers and 10000 steps took 27.300215482711792 seconds.
Scene with 10 controllers and 10000 steps took 54.59787082672119 seconds.
after:
Scene with 1 controllers and 10000 steps took 0.12163424491882324 seconds.
Scene with 5 controllers and 10000 steps took 0.18189406394958496 seconds.
Scene with 10 controllers and 10000 steps took 0.27340126037597656 seconds.

--> with 10controllers, 200x faster... 😲

macOS (xcode26, M3 max)

before:
Scene with 1 controllers and 10000 steps took 8.079632759094238 seconds.
Scene with 5 controllers and 10000 steps took 40.43093395233154 seconds.
Scene with 10 controllers and 10000 steps took 79.13048505783081 seconds.

after:
Scene with 1 controllers and 10000 steps took 0.03541707992553711 seconds.
Scene with 5 controllers and 10000 steps took 0.06284904479980469 seconds.
Scene with 10 controllers and 10000 steps took 0.09451079368591309 seconds.

--> with 10controllers, 837x faster... 🤪

alxbilger

Is the cache system also relevant for other trampoline classes?

fredroy · 2026-02-03T22:11:56Z

Is the cache system also relevant for other trampoline classes?

To my meager knowledge, I would say yes. But in this case it is especially useful because there were(are) many lookups to call implicitly all the *event() every step.

bakpaul · 2026-02-04T13:58:12Z

Nice cache mechanism. Now I wonder what would happend if someone changed dynamically the method after it has already been cached :

MyController.onAnimateBeginEvent() # Cache is now active for this method
MyController.onAnimateBeginEvent = randomMethod # Cache is now invalid
MyController.onAnimateBeginEvent() # now what's called ?

Maybe we could add a setattr overloead invalidating the cache when it is called on a method already cached ?

fredroy · 2026-02-04T23:02:24Z

Nice cache mechanism. Now I wonder what would happend if someone changed dynamically the method after it has already been cached :
MyController.onAnimateBeginEvent() # Cache is now active for this method
MyController.onAnimateBeginEvent = randomMethod # Cache is now invalid
MyController.onAnimateBeginEvent() # now what's called ? 
Maybe we could add a setattr overloead invalidating the cache when it is called on a method already cached ?

no idea, I even did not know you could change class method dynamically like that 🙃

hugtalbot · 2026-02-05T09:08:29Z

@damienmarchal your review would be most valuable here 🙏

fredroy · 2026-02-10T00:52:26Z

Nice cache mechanism. Now I wonder what would happend if someone changed dynamically the method after it has already been cached :
MyController.onAnimateBeginEvent() # Cache is now active for this method
MyController.onAnimateBeginEvent = randomMethod # Cache is now invalid
MyController.onAnimateBeginEvent() # now what's called ? 
Maybe we could add a setattr overloead invalidating the cache when it is called on a method already cached ?

@bakpaul Claude judged you a little bit : reassigning event handlers at runtime on a controller instance is arguably an unusual pattern 🙃

but his suggestion is similar to yours.

fredroy · 2026-02-10T00:53:53Z

The new commit manages the reassignment, and I add a test to check (https://github.com/fredroy/SofaPython3/blob/492512136c3ab47b2665931b241d52a44a260c02/examples/tests/testReassignmentController.py)
before it was printing:

Controller0 : onAnimateBeginEvent
Controller1 : onAnimateBeginEvent
Controller2 : onAnimateBeginEvent
Controller0 : onAnimateBeginEvent
Controller1 : onAnimateBeginEvent
Controller2 : onAnimateBeginEvent

after it prints:

Controller0 : onAnimateBeginEvent
Controller1 : onAnimateBeginEvent
Controller2 : onAnimateBeginEvent
Controller0 : modifiedAnimateBeginEvent
Controller1 : modifiedAnimateBeginEvent
Controller2 : modifiedAnimateBeginEvent

damienmarchal · 2026-02-10T09:32:07Z

@damienmarchal your review would be most valuable here 🙏

I will... nice PR.

bakpaul · 2026-02-19T10:06:41Z

@damienmarchal, still waiting for your review

damienmarchal · 2026-02-19T11:38:26Z

OMG we are thursady, thank for pointing the pending review.

damienmarchal · 2026-02-19T11:43:47Z

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.cpp

+    if (f_printLog.getValue())
+    {
+        std::string eventStr = py::str(PythonFactory::toPython(event));
+        msg_info() << "on" << event->getClassName() << " " << eventStr;
+    }


As msg_info() already contains f_printLog.getValue() test this should be implemented with one-liner more or less like:

msg_info() << "on" << event->getClassName() << " " << py::cast<std::string>(py::str(PythonFactory::toPython(event)));

I'm a bit puzzled by the conversion chain from event to python, to str, to string. Cannot we have a direct c++ event to std::string ?

As msg_info() already contains f_printLog.getValue() test this should be implemented with one-liner more or less like:

msg_info() << "on" << event->getClassName() << " " << py::cast<std::string>(py::str(PythonFactory::toPython(event)));

but even if the msg_info() is not printed, py::cast<std::string>(py::str(PythonFactory::toPython(event)) will still be executed (for nothing as we dont want the print) no ?

I'm a bit puzzled by the conversion chain from event to python, to str, to string. Cannot we have a direct c++ event to std::string ?

AFAIK (but I may be wrong) there is no serialization of an Event in Sofa C++ so it needs to be done first.

I'm not sure the cast part will be executed because the msg_info() has been specifically implemented so that the right side of conditional on-liners messages cost nothing in case the condition is false.

So unless a makes a mistake, the code you are pointing is actually equivalent to:

if( sofa::helper::logging::notMuted(this) ) // Test the condition and if true create the message and << into it... sofa::helper::logging::MessageDispatcher::info(sofa::helper::logging::Message::Runtime, sofa::helper::logging::getComponentInfo(emitter), SOFA_FILE_INFO) << "on" << event->getClassName() << " " << py::cast<std::string>(py::str(PythonFactory::toPython(event)));

Side note: I would vote for event serialization in c++ ;)

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.cpp

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.h

damienmarchal · 2026-02-19T12:06:55Z

@bakpaul thank for poking for review. Done now.

Summary of Modifications The changes in this branch (speedup_controller) optimize the Controller_Trampoline class in the Python bindings by adding a caching mechanism for Python method lookups: Key Changes: 1. New caching infrastructure (in Binding_Controller.h): - Added member variables to cache: - m_pySelf - cached Python self reference (avoids repeated py::cast(this)) - m_methodCache - unordered_map storing Python method objects by name - m_onEventMethod - cached fallback "onEvent" method - m_hasOnEvent / m_cacheInitialized - state flags 2. New methods (in Binding_Controller.cpp): - initializePythonCache() - initializes the cache on first use - getCachedMethod() - retrieves methods from cache (or looks them up once and caches) - callCachedMethod() - calls a cached Python method with an event - Constructor and destructor to properly manage the cached Python objects with GIL 3. Optimized handleEvent(): - Previously: every event caused py::cast(this), py::hasattr(), and attr() lookups - Now: uses cached method references, avoiding repeated Python attribute lookups 4. Optimized getClassName(): - Uses the cached m_pySelf when available instead of casting each time Purpose: This is a performance optimization that reduces overhead when handling frequent events (like AnimateBeginEvent, AnimateEndEvent), which can be called many times per simulation step. The caching eliminates repeated Python/C++ boundary crossings for method lookups.

…handler reassignment

fredroy · 2026-02-27T01:57:01Z

@bakpaul thank for poking for review. Done now.

applied @damienmarchal suggestions (particularly the simplification)

fredroy added enhancement New feature or request pr: status to review pr: clean-fix pr: highlighted in next release Highlight this contribution in the notes of the upcoming release topic for next dev-meeting Worth discussion at dev meeting labels Feb 3, 2026

alxbilger reviewed Feb 3, 2026

View reviewed changes

fredroy force-pushed the speedup_controller branch from 57debb4 to 040d3e6 Compare February 4, 2026 02:31

bakpaul approved these changes Feb 4, 2026

View reviewed changes

fredroy force-pushed the speedup_controller branch from 040d3e6 to 63b1a8d Compare February 5, 2026 00:29

hugtalbot assigned damienmarchal Feb 5, 2026

bakpaul approved these changes Feb 10, 2026

View reviewed changes

hugtalbot removed the topic for next dev-meeting Worth discussion at dev meeting label Feb 12, 2026

fredroy force-pushed the speedup_controller branch from 4925121 to 0cb5d02 Compare February 13, 2026 02:43

damienmarchal reviewed Feb 19, 2026

View reviewed changes

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.cpp Outdated Show resolved Hide resolved

damienmarchal reviewed Feb 19, 2026

View reviewed changes

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.cpp Outdated Show resolved Hide resolved

damienmarchal reviewed Feb 19, 2026

View reviewed changes

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.cpp Outdated Show resolved Hide resolved

damienmarchal reviewed Feb 19, 2026

View reviewed changes

bindings/Sofa/src/SofaPython3/Sofa/Core/Binding_Controller.h Outdated Show resolved Hide resolved

fredroy added 2 commits February 27, 2026 10:56

add test

9b48fa0

fredroy added 5 commits February 27, 2026 10:56

Invalidate Controller method cache on __setattr__ to support runtime …

811a454

…handler reassignment

add test on reassigment

1c41d80

remove unnessary test

8579a1b

check if the value is callable

10438e3

Unify onEvent into m_methodCache

486c35c

fredroy force-pushed the speedup_controller branch from 0cb5d02 to 486c35c Compare February 27, 2026 01:56

Conversation

fredroy commented Feb 3, 2026

Ubuntu 22.04 (gcc12, i7 13700k)

Windows (MSVC2026, i7 11800h)

macOS (xcode26, M3 max)

Uh oh!

alxbilger left a comment

Choose a reason for hiding this comment

Uh oh!

fredroy commented Feb 3, 2026

Uh oh!

bakpaul commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fredroy commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hugtalbot commented Feb 5, 2026

Uh oh!

fredroy commented Feb 10, 2026

Uh oh!

fredroy commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

damienmarchal commented Feb 10, 2026

Uh oh!

bakpaul commented Feb 19, 2026

Uh oh!

damienmarchal commented Feb 19, 2026

Uh oh!

damienmarchal Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

fredroy Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

damienmarchal Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

damienmarchal commented Feb 19, 2026

Uh oh!

fredroy commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

bakpaul commented Feb 4, 2026 •

edited

Loading

fredroy commented Feb 4, 2026 •

edited

Loading

fredroy commented Feb 10, 2026 •

edited

Loading

damienmarchal Feb 27, 2026 •

edited

Loading