[quoted text, click to view] >What's the performance impact of running a .NET smtp sink? Is is much slower
>compared to delphi and/or c++?
The answer is, per usual: it depends. A C++ sink could give you a
2x-10x performance edge over an exactly equivalent .NET sink due
purely to differences in the runtime environment. Yet in the real
world, you're far more likely to encounter performance ceilings in a
sink due to overuse of the CDO API (rather than writing your own
functions or using higher-performance third-party libraries), or due
to overuse of poorly performing .NET classes and integrated controls,
or due to other stuff you just shouldn't try to do in the relatively
uncontrollable environment of a public-facing MX (hint: semaphores and
such are definitely your friend if you can't control the number of
concurrent connections, and thus concurrent function calls), than you
are to really choke simply because you've chosen .NET. So, it
depends. . . on what your sink is trying to do, how much time it has
to do it, and how many other instances (i.e. msgs/sec or msgs/day) are
going to try to do it at the same time on the same box.
My opinion is that the developer-facing kludges currently necessary to
implement managed sinks make for uglier code, regardless of the
user-facing performance issues, and since the managed code simply
cannot give you higher performance (though it may give you essentially
equivalent perf), I still stick with C++. Also, I'd say the chances
are slim that these kludges will be necessary in future as the sink
API becomes more readily .NET-compatible, so you'll end up rewriting
your interim ugly code, anyway. So it may come down to your comfort
level with C++/Delphi vs. your desire to "live" completely within the
..NET IDE going forward, etc.
Sorry I can't be less general, but it seems to really depends on a
sink's actual specifications.
