Click here to Skip to main content
15,923,120 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
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)

-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)

Thanks for helping me out :-
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).

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.)

Share this answer
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.
Maciej Los 5-Jun-13 1:58am    
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...
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:

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

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.
Share this answer
Maciej Los 4-Jun-13 17:39pm    
Well explained.
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.
It'll be on the thread that called CreateInstance.
Share this answer

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

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900