Click here to Skip to main content
15,887,485 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
We are building a solution for a generic application that can have dlls removed/reinstated to support flexibility of the internal modules. It is required as a platform that a specific implementation can replace existing modules with ones it wants to run/test etc.

For example, a specific implementation can simply write it's own dll to replace the original ModuleA and it works fine since the fitted new ModuleA replacement implements IModuleA. In this way, a user of the application can fit in his modules without having to compile the generic application.

To allow this kind of methodology, any replaceable module is it's own project, thus complied to another dll.

My question: Is there any performance hindrance working like that with numerous dlls instead of a small number of dlls?
Posted
Updated 16-Jul-15 1:39am
v2
Comments
Richard MacCutchan 16-Jul-15 7:53am    
It depends. If the DLLs are reasonably small and used consistently then there should be no real performance hit. But if the application uses many different DLLs and loads and reloads them then there could be a quite considerable problem.
Jo Mua`mar 16-Jul-15 7:56am    
Many different DLLs but no runtime reloading
Richard MacCutchan 16-Jul-15 8:04am    
So it's all down to you running the performance tests. No one can predict what the actual behaviour will be.

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