Introduction
This solution demonstrates as simply as possible how to leverage inline assembly and C++ ATL from a C# project. This architecture may be used to optimize .NET web services, .NET web applications, .NET Windows applications and .NET Windows services without any third party assemblers. This is particularly useful for optimizing C# code with C++ in Visual Studio .NET centric build environments, brought to you by �Free and easy artificial intelligence chatbot hosting�.
Does the COM layer slow it down?
The COM layer itself is very slow for this example and this architecture will not be efficient for small calculations. This is more practical for real-time embedded systems such as medical devices or aerospace where large calculations must be completed fast. Rather then being limited to C++ developers, the company can use this architecture to their C# developers and then a few C++ developers to optimize the large algorithms in ASM. This can even more easily be done without the COM layer via linking a 100% ASM DLL into the .NET project but lacks the benefits of tool tips, reference counting, deployment version control etc.
This example simply provides a minimal example of C#->ATL/C++->Inline Assembly/ASM because a complex algorithm would make it less feasible for most users to understand the architecture.
In short, overhead for COM Marshaling is relatively constant and algorithm complexity grows. Hence the larger the calculation, the overhead of the COM marshaling time becomes smaller relative to the calculation time. Far too often coders go all out on optimization and loose things like tooltips for the sake of optimization, forgetting that the overhead of marshaling is relatively small compared to their optimization.
O(COM Marshaling Overhead + algorithm execution time)
For example, if the COM marshaling overhead is lets say 2 units of time and the execution time (in this example) is 0.00001, the overhead is larger then the algorithm execution time. However, if the algorithm takes 100 units of time in C# and 50 units of time in C/C++/ASM, then the time to execute is 50 units of time + 2 units of time. The overall time is 52 units of time which is relatively close to 50 units of time (as would be the case of directly including an ASM DLL and skipping the COM layer and loosing tooltips). For most business needs, 2 more units of time for COM marshaling is worth the scalability advantages when their algorithms take 50 units of time.
What are tool tips and how can ASM binaries have tooltips?
Tooltips include: auto-complete triggered by member access operators in an IDE, mouse over bubble help that shows signature info, etc. These are not possible with primitive ASM binaries. And no, you will not have tool tips if you build an ASM binary and link it into a .NET application as .NET application, unless you exposed standard COM or other .NET recognized architecture. That would be a substantial amount of unnecessary work and would destroy the feasibility for large ASM optimizations. Anyhow, tooltips and supporting architectures is outside the scope of this article. But just for kicks, in the ATL case, ATL generates code that exposes an interface called IDispatch as well as a direct �vtable� interface, when �duel� is selected in the ATL wizard, which is called by the target IDE (.NET interop, VB6, etc.) used to generate tooltips during development of the binary�s host. Many other architectures are used by IDEs to generate tool tips, for example when .NET makes a web reference to a SOAP server that exposes WSDL, the WSDL is downloaded and used to generate tooltips for the SOAP server�s methods. For an example of WSDL that is used to generate tooltips in .NET IDEs see the TANU WSDL[^].
