search

dss-extensions / dss_sharp

C#/.NET bindings for DSS C-API, an unofficial implementation of OpenDSS with a custom API in plain C, new features and API extensions.
https://dss-extensions.org/dss_sharp/
BSD 3-Clause "New" or "Revised" License
8 stars 0 forks source link

.NET 7: LibraryImportAttribute #14

Closed PMeira closed 1 year ago

PMeira commented 2 years ago

From P/Invoke source generation | Microsoft Docs:

.NET 7 introduces a source generator for P/Invokes in C# which recognizes the LibraryImportAttribute.

.NET adoption is all over the place in terms of versions (a lot of people stuck with old Framework versions), but LibraryImportAttribute could reduce the overhead. This could be especially good for a future alternative API that would mirror dss::obj. For the moment we're already faster than the COM implementation in a lot of the API.

.NET 7 is still in the preview stage, so we have time to test before the final release (expected by the end of the year).

PMeira commented 2 years ago

Related: https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/

PMeira commented 1 year ago

Turns out just using LibraryImport doesn't actually help much for DSS Sharp. The reason is that we already migrated to DSS C-API's GR interface, which API buffers to optimize some operations.

Allowing something like ArrayPool would also be nice but I don't see it fitting in the current ("classic") API.

Source generators still might be useful for our future plans, including the new API. But, since there are thousands of functions in the API, we have to weight the benefits, that is, if the assembly gets too bloated, it will actually be slower. That's another issue though, so closing this for now.

For numeric data DSS Sharp was already quite faster than using the COM DLL (or OpenDSSDirect.DLL) due to the architecture of the official APIs, so this is not really a point of concern.