This might sound as a weird question, but in my department we are having trouble with following situation:
We are working here on a server application, which is growing larger and larger, even at the point that we are considering to split it into different parts (DLL files), dynamically loading when needed and unloading afterwards, in order to be able to handle the performance issues.
But: the functions we are using, are passing input and output parameter as STL objects, and as mentioned in a Stack Overflow answer, this is a very bad idea. (The post contains some ±solutions and hacks, but it all does not look very solid.)
Obviously we could replace the input/output parameters by standard C++ types and create STL objects from those once inside the functions, but this might be causing performance drops.
Is it OK to conclude that, in case you are considering to build an application, which might grow that large that one single PC can't handle it anymore, you must not use STL as a technology at all?
More background about this question:
There seem to be some misunderstandings about the question: the issue is the following:
My application is using huge amount of performance (CPU, memory) in order to complete its work, and I would like to split this work into different parts (as the program is already splitted into multiple functions), it's not that difficult to create some DLLs out of my application and put some of the functions in the export table of those DLLs. This would result in following situation:
+-----------+-----------+----
| Machine1 | Machine2 | ...
| App_Inst1 | App_Inst2 | ...
| | |
| DLL1.1 | DLL2.1 | ...
| DLL1.2 | DLL2.2 | ...
| DLL1.x | DLL2.x | ...
+-----------+-----------+----
App_Inst1 is the instance of the application, installed on Machine1, while App_Inst2 is the instance of the same application, installed on Machine2.
DLL1.x is a DLL, installed on Machine1, while DLL2.x is a DLL, installed on Machine2.
DLLx.1 covers exported function1.
DLLx.2 covers exported function2.
Now on Machine1 I'd like to execute function1 and function2. I know that this will overload Machine1, so I'd like to send a message to App_Inst2, asking that application instance to perform function2.
The input/output parameters of function1 and function2 are STL (C++ Standard Type Library) objects, and regularly I might expect the customer to do updates of App_Inst1, App_Inst2, DLLx.y (but not all of them, the customer might upgrade Machine1 but not Machine2, or only upgrade the applications but not the DLLs or vice versa, …). Obviously if the interface (input/output parameters) changes, then the customer is forced to do complete upgrades.
However, as mentioned in the referred StackOverflow URL, a simple re-compilation of App_Inst1 or one of the DLLs might cause the whole system to fall apart, hence my original title of this post, dis-advising the usage of STL (C++ Standard Template Library) for large applications.
I hope that hereby I've cleared out some questions/doubts.
Best Answer
This is a stone-cold classic X-Y problem.
Your real problem is performance issues. However your question makes it clear that you've done no profiling or other evaluations of where the performance issues actually come from. Instead you're hoping that splitting your code into DLLs will magically solve the problem (which it won't, for the record), and now you're worried about one aspect of that non-solution.
Instead, you need to solve the real problem. If you have multiple executables, check which one is causing the slow-down. While you're at it, make sure it actually is your program taking all the processing time, and not a badly-configured Ethernet driver or something like that. And after that, start profiling the various tasks in your code. The high-precision timer is your friend here. The classic solution is to monitor average and worst-case processing times for a chunk of code.
When you've got data, you can work out how to deal with the problem, and then you can work out where to optimise.