COM vs dss_matlab speed comparison for setting loads and getting currents; handle classes are slow

[Hell3000]

here is the speed comparison I promised in DSS Disussion Forum https://sourceforge.net/p/electricdss/discussion/861976/thread/a096cdeed4/?limit=100#a3e1/261b

Summary

setting loads and getting currents is currently (November 2024) much slower (about 7 times) using altDSS compared to COM-Interface.

The main reason is: Matlab handle classes still have huge overhead.

Workaround: calling libs directly. Then altDSS is only about 1.5 times slower than COM-Interface.

Also: 2021b and 2024 b are faster than old 2019b (maybe something like 20 %). But handle classes are still too slow!

Conclusion: handle classes are not a good option. There might be a better way to emulate COM-Interface.

speed comparision of altDSS and COM and 2019b vs 2024b

this is on windows 10 VM with newest DSS (100_2, temporary trick to install Regsvr32 "C:\Program Files\OpenDSS\x64\OpenDSSEngine.DLL")

Code used for comparison

I attached a grid file with lines and loads and a .m Matlab file. It should be executable.

To execute:

1. rename .txt of Matlab file to .m
2. install DSS (https://sourceforge.net/p/electricdss/discussion/861977/thread/d97878c8f4/?limit=25 workaround might be needed)
3. Download dss_matlab
4. modifiy Base.m of dss_matlab as described in the attached Matlab file
5. add necessary to MATLAB path
6. Check code for safety
7. Run

speed_of_altDSS_vs_COM_m_file.txt
LV_grid.txt

Suggestion for getAllLineCurrents makro in the code as Matlab Code

of course this must be implemented in C++ to have a speed benefit.

[PMeira]

OpenDSS v10.2 was released last week, so I'm finally getting back to this. New releases here on DSS-Extensions are planned by the end of next week, including support for the official engine.

There are actually multiple issues that slowed down DSS_MATLAB through the years. Some notes:

• MATLAB's COM implementation got faster through the new versions, I don't know exactly which versions though. The performance target moved.
• Handle classes indeed are slow as you detailed. I think we can safely remove handle from Base.m and it already removes a lot of overhead. Removing handle from APIUtil.m doesn't seem change anything in terms of performance, and that's where handles might be really required nowadays.
• Another source of overhead is the ctx and library name arguments passed through calllib. Using calllib directly and removing the ctx argument speeds things enough seems to be faster than the current COM implementation.
  • In this case, assuming only the main/prime DSS context is used (like in COM), appending the non-ctx functions to dss_capi_no_thunk.m (copying from old version works for most functions).

If we don't finish the new MEX version by next week, I'll update the current version to include the changes above.

Regarding the MEX version:

• We previously started tests in 2020-2021 in DSS_MATLAB
• Recently, we rewrote the core of the Python packages using Python's and NumPy's C-API directly, in a module we call FastDSS.
• A lot of the code from FastDSS can be reused here, so we're porting FastDSS to MEX now.

Suggestion for getAllLineCurrents makro in the code as Matlab Code

Yep, adding those too. Probably for most of the API that represents data and state.

[Hell3000]

Thank you for the Infos and the Implementation. Sounds great!

[PMeira]

Mostly done, working now on the initial batch API (e.g. read/write all values for a component type). The numbers are looking good.

Handle classes indeed are slow as you detailed

An update: it seems that they're not always slow. Running the tests/benchmarks inside a function, I didn't always notice any difference. Still, most classes don't require handles and we could remove them.

I also noticed that property setters on Windows are quite slow, but don't seem to have much overhead on Linux. It might be worth adding dedicated setter functions (e.g. Loads.set_kW()) for all setters. Probably worth adding some minimal benchmarks to run on GitHub Actions too, since MATLAB performance profile is different across versions and OSes.

We should keep the classes for easier porting from COM, but calling the MEX gateway function could be useful sometimes. We better add some examples later.

Suggestion for getAllLineCurrents makro in the code as Matlab Code

of course this must be implemented in C++ to have a speed benefit.

The following are the runtime ratios of COM / MEX for some benchmarks, using IEEE 8500 test circuit.

	MEX (AltDSS engine)	MEX (AltDSS Oddie+OpenDSSDirect.DLL)
Read all Loads.kW (MATLAB loop)	4.5	4.3
Write all Loads.kW (MATLAB loop)	5.5	4.7
Batch read all kW (MEX loop)	190	90
Batch write all kW (MEX loop)	67	28
Read Circuit.AllBusVolts	10.8	9.1
Read Circuit.AllBusVmagPu	6.7	4.4
Read CktElement.Powers	5.0	4.4

Ignoring the setter overhead I mentioned above (not present in the table), I'm seeing that the OpenDSS COM impl. through MATLAB is 3-7x slower than the new MEX code, and of course the batch operations are much faster. I'm avoiding comparing to OpenDSS-C right now to save some time, we can add it later.