SV: [vtkusers] c# port of VTK

[Lars Overgaard]

Sorry, it was never my intention to question anybody's credibility. And
I am not the one to say whether or not wrappers are the best solution
for vtk-C#.

Rather, my point is that C# is special - a beauty, and a real beast!
.Net and managed code introduce a HUGE overhead on function calls and
data referencing - and automatic garbage collection, not to mention. A
C# port/wrap/what-ever that does not take this into account could end up
with a computational performance that is a fraction of what was
expected. In case of frequent C#->vtk interface calls, it could mean not
just lost microseconds but rather lost hours.

A vtk wrapper is much easier to maintain than a port, no doubt. On the
other hand, wrapping reduces performance. It's a classical choice
between maintenance and performance. Usually, the performance cost of a
wrapper is quite small, and a wrapper is the obvious choice.

In case of C#, the huge .Net overhead makes the choice less obvious.

Best regards,
- Lars


>>> It's relatively easy to create wrappers for vtk and the overhead is 
>>> minimal in calling them. A lost microsecond when processing hundreds

>>> of MB of data is not worth saving.
 
>> In general, wrappers have advantages, no doubt about that. But C# is 
>> no just yet another programming language - a lot of things go with 
>> .net. I wonder if this comment comes out of real experience with C# 
>> and managed C++/C wrapping? I think that the overhead can actually 
>> become quite substantial. Great care must be taken to obtain an 
>> efficient C#-based VTK.

>    I cannot speak for John, but I never took him to be referring to 
> C#. Rather, he references the considerable experience of himself and 
> others in using VTK via one of its current wrappers (Java, Python, and

> Tcl). His comment is pretty solid and should be applicable.