referenced dll

In an effort to better organize my existance, I've been trying to build some class libraries recently. Out of curiosity I ran a comparison between two versions of the same script component, one referencing a dll the other with the equivalent classes built internally. I was surprised to see compenent with the dll reference running considerably slower. Is this typical or did I miss something on the visual studio side of things?

Dave

Replies to This Discussion

Permalink Reply by Damien Alomar on March 9, 2011 at 4:03pm

Hmm... since you said this is a scripting component, not a custom component, then I think that would depend on how David is dealing with referenced assemblies in scripting components. Basically, when you compile code into a dll, it gets compiled into IL (intermediate language), which is the common denominator between all the .Net languages and is what the .Net framework actually uses to create assembly/processor instructions at run time.

This process of taking the IL and compiling it into code that's usable by the computer is called JIT, or just in time compiling. This process does take a little time, but for most code within the managed environment, this happens once when the assembly is initially loaded, and then it stays in memory, so that performance hit isn't seen on subsequent runs. What may possibly be happening here is that each time the scripting component is run, the assembly is loaded, compiled, used within your script, then unloaded. If that is the case, then subsequent runs of the component would not benefit from the assembly already being loaded/compiled. I guess we'll need more word on exactly how these referenced assemblies are being handled.

If they are being loaded and unloaded with each scripts execution, there is the capability to "precompile" the IL into a native dll. This would save some time, although the code that is created by the "precompiled" dll is not optimal because things like processor architecture (x86 vs x64), memory locations, etc are not known. In this case though, I would imagine that it would offer some performance benefit though.

Permalink Reply by David Reeves on March 10, 2011 at 4:19am

Thanks Damien. Very Informative. The script component in question is rigged up to a timer and holds geometry between solutions in some additional shared Script_Instance members. I added some extra junk within both components to see how the time differential changes when things slow down. It seems like the component with the reference is always running around half speed. Does this sound symptomatic of the loading/unloading scenario?

Permalink Reply by David Rutten on March 10, 2011 at 5:37am

Hi Dave,

slower overall or slower only the first time? Compiling a VB/C# script takes longer if there are special references, but once compiled there should be no difference.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Reeves on March 10, 2011 at 1:58pm

Hi David,
Slower overall. It's pretty consistent about it, solving each iteration at about half speed.

Permalink Reply by David Rutten on March 10, 2011 at 3:36pm

Odd, it's actually impossible to unload a dll from an AppDomain in .NET so whatever is causing the slowdown, it is certainly not due to a continuous reloading of a dll. I'll run some tests once I have the Ants profilers installed again.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Damien Alomar on March 10, 2011 at 8:50pm

Didn't know that one. Thanks for the extra info. Let me know how useful that Ants profiler is. I was looking at it today. The price tag is probably a little too steep for my budget though.

Permalink Reply by David Rutten on March 11, 2011 at 3:45am

I've used an older version, and was never a very advanced user, but I liked it a lot.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Reeves on March 10, 2011 at 5:35pm

Just an update.
After streamlining some of the code it seems to have mysteriously sorted itself out. The two components are running identically. I'm not exactly sure what was causing it in the first place but I'd hate to send you on a wild goose chase David. I'll let you know if I run into it again.

Permalink Reply by David Rutten on March 10, 2011 at 5:41pm

Ok thanks. Glad it worked out :) Could it be that you compiled the referenced dll as DEBUG first and as RELEASE second? That might explain a difference in performance.

David Rutten

david@mcneel.com

Poprad, Slovakia

RSS