Preformance Question when loading optional DLL

Question

0.00/5 (No votes)

See more:

Question:
From a performance standpoint, should I load the optional DLL in it's own tread or does this already happen because I'm using reflection ?

When calling my DLL sub , what thread will this be running off ?

- Below is part of the code I'm using to load the DLL MainForm:

GenericInstance = Activator.CreateInstance(KDMDLL.GUI_MainForm)
KDMCustomGUI = CType(GenericInstance, Form)
KDMCustomGUI.Show()

-I'm further calling the Subs in my DLL with something like this

Dim Arguments() As Object = {CType(SubName, Object), Par}
Dim A As Object = Activator.CreateInstance(KDMDLL.GUI_Class)
KDMDLL.GUI_INTERFACE_SUB.Invoke(A, Arguments)

Thanks for helping me out :-

Posted 4-Jun-13 10:58am

Georg Kohler

Add a Solution

Comments

Sergey Alexandrovich Kryukov 4-Jun-13 17:13pm

I doubt it will happen in a separate thread (not 100% sure), but you won't really gain anything if you do it in a separate thread. (How?)
You should also understand that loading of an assembly itself is really fast, as it is not immediately compiled from CIL. JIT compilation makes spending time on compilation postponed, distributed over time as methods/properties get loaded as they are needed. Besides, reflection takes considerable time. You can reduce reflection use to minimum by using some architectural approach, which I can explain if you want (it's not related much to your main question).
—SA

3 solutions

Solution 2

Please see my comment to the question. As you can see, I'm not sure about some detail. But practically, I would answer: doing it in a separate thread makes no sense. Yes, I'm pretty much sure.

(By the way, threads are rarely used to improve performance. They effectively can improve throughput, but this is not the same, and is not the main purpose of threads. For a warm-up exercise, imaging you have a two-code CPU and only one task with some limited number of operations, let's say, many. Apparently, you can make it fast, if you break it in two thread, if this is possible (there are independent sub-tasks). But how about more threads? Isn't it apparent that they would only slow down obtaining the final result. This is if you are not going to change any parameters of this task. But what if you want to change them manually depending on observation of intermediate results. Then UI thread will make it more efficient, even though you don't accelerate anything, just because you would stop wasting time for useless part of calculations.

Threads are more for logic, less for performance.)

—SA

Posted 4-Jun-13 11:20am

Sergey Alexandrovich Kryukov

Updated 4-Jun-13 11:21am

v2

Comments

Maciej Los 4-Jun-13 17:38pm

Reasonable ;)
But i can't agree with this part: Threads are more for logic, less for performance of your answer ;)laugh;)

By the way, can you take a look at this thread: Picture Password in VB.NET[^]?

Sergey Alexandrovich Kryukov 4-Jun-13 17:54pm

Thank you, Maciej.

As to agreement with "more for logic", before being agree or disagree, please note that this statement, as it can be seen from the context, does not have an absolute character. "More" and "less" are always relative values. Please see the previous paragraph. I consider certain situations as more typical, but of course it depends on what work people do. I mostly face with having logically parallel activities and scenarios (communication vs. logic), keeping UI responsive. It is related to productivity and even throughput, but not really performance. Also, most questions of these forum are related to logical parallelism, but hardly performance. Performance boost through threads is only considerable if you have spare cores/CPUs...

I just saw your answer to the question on picture password. I think you go along the line which is not most important. This important part is the drawing recognition. Your answer is nice but cannot change anything essential.
—SA

Maciej Los 5-Jun-13 1:58am

Sergey,
About threads: it was a joke. I do really understand your point ;)
About "Picture Password...": i'd like to take up your focus on OP's comments ;)
Anyway, thank you for your opinion.

Sergey Alexandrovich Kryukov 5-Jun-13 2:07am

Hm. By some reason, I failed to notice ironic intonation between your words in printing... :-)
Thank you, I'll look again...
—SA

Solution 1

It'll be on the thread that called CreateInstance.

Posted 4-Jun-13 11:07am

Dave Kreskowiak

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ron Beyer · Accepted Answer · 2013-06-04T11:27:00

Solution 3

When loading in a DLL you are loading into the current AppDomain (at least using the methods you describe in your question). When you are loading it, the load happens in the same thread that calls the function that loads the DLL.

As SA said, loading a DLL into an AppDomain is very fast, as the code is not compiled or JIT'd until its actually run. The problem you may have however is a little different. All UI components run on the same thread (the UI thread), so you really can't load your form into a different thread, it'll always be on the UI thread.

The slow part is the "invoke", which uses reflection. I'm really not sure the best way around this in VB, but in C# if we know the method name prior to compile time we can use dynamic methods, like:

C#

dynamic userForm = Activator.CreateInstance("KMDLL.GUI_MainForm");
userForm.SomeProperty = somevalue;
userForm.SomeMethod();

The operator on the right side of the "." isn't evaluated until run time, so we can call anything we want without the compiler complaining that it doesn't exist. This is faster than using Invoke, invoke is up to 100 times slower than just calling the method. Look up faster was to do invoking on google for more help.

Posted 4-Jun-13 11:27am

Ron Beyer

Comments

Maciej Los 4-Jun-13 17:39pm

Well explained.
+5!

Georg Kohler 4-Jun-13 18:01pm

So what you're saying, is that if the code indside the [userForm.someMethode()] task a long time, the UI thread will wait until it's process ?

Maybe I should to explain a bit more about my specific situation

I have a separate thread that reads axis positions(up to 6 axis) from a motion controller at a given interval( programmable but usually 100ms-200ms)
now I need to pass the Pos values to my DLL (if it's loaded)
I'm trying to determine, if I can safely do this without missing my readout "beat" of 100ms
Obviously I was wondering If it would make sense, to pass tasks in the DLL to a separate thread

Ron Beyer 4-Jun-13 18:12pm

You may want to look at asynchronous methods, but yes, userForm.SomeMethod called as per the above will block until it returns. You can use delegates and BeginInvoke to run them asynchronously or there are other ways to do it (using background workers, etc).

Georg Kohler 4-Jun-13 18:19pm

Ok that makes sense ...

Ron Beyer 4-Jun-13 18:32pm

BTW, there are a multitude of timers available, and its really unfortunate that the Windows.Forms.Timer is the one most people use. This is the worst performing timer of the choices you have, if you aren't already, I'd use System.Threading.Timer instead.

Sergey Alexandrovich Kryukov 4-Jun-13 20:43pm

Good points. I would say, activation part of the answer is a bit native. It's always a bad thing to activate anything by name, because this is not supportable, a compiler won't warn is you misspell anything, etc.
This is not really needed, if you create an appropriate architecture. The simplest solutions is: create some "plug-in interface". If could be defined in separate assembly, but even the host assembly is fine, as plug-in can actually reference host assembly (even if this EXE, for .NET it does not matter at all). So, the interface should be known to both host and plug-in. It removes performance problem, as you call everything through the interface(s), and you use reflection only to find and activate the class implementing plug-in (or all classes implementing all plug-ins; the essential part here is that interfaces can be of any complexities, but the number of implementing classes and interfaces are always very small).

Now, I accelerate even the search for the implementing class withing the assembly. You can check from reflection that some class implements some interface. But you don't have to do it for all classes. I use a special .NET attribute of assembly target (assembly-level). Attribute may have System.Type parameter types, so you can use typeof to specify implementing class. So, the attribute just says "this class is claimed to be implementing class, don't look further". The host uses Reflection to find the attribute. If such attribute not found, it says "wrong assembly" and goes ahead. By attribute, you have the type and immediately check up if it implements the interface you need. If not, the host says "wrong assembly" and goes ahead. If found, reflection looks for appropriate constructor. If not found, the host says "wrong assembly" and goes ahead. And if it is found, invokes it and casts to interface type. Done. Only 5 assembly operation for whole plug-in; it's nothing.

This way, this performance problem is also not considerable.

(I voted 4.)

Cheers,
—SA