Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Minimize size of application in memory with Oracle DB
I have developed in Qt 4.8 (with MSVS2008) application that is connected to OracleDB using oracle instant client and QOci sqlplugin.
After developing basic functionality, it's time for optimizations.
Now to the question...
My application takes 30 MB of memory ( Release Build, also tryed Optimized Size in compiler).
After some research I found out with VMMap, that my application is so big just because of dlls that are loaded for oracle.
It's no big problem with one instance of application, but my application will have 36 and later 48 instances. That means it will take ~1.5GB of memory, which is not acceptable.
How to solve this problem ?
One possibility is to have access point to database in dedicated server app, and my application behaves as client (TcpSockets), but that will be last option. Can I force static build of application, that EXE will contain only needed functionalitys from oracle DDLs ?
And suggestion will be appriciated.
King regards slopixi
mcosta last edited by
one question: "Why you need to launch 36/48 instances"?
If you really need them, I suggest to split in client/server model
More details can be helpfull to suggest better solutions
Instances are needed because of USB connection to hardware ( One usb channel per instance).
This is achived wich dedicated hardware.
So my problem is that every instance of application loads dll called 'oraociei11.dll' from oracle instant client and every loaded dll takes about 30MB. Is there any possibility that this dll would be shared among my application instances ( some compiler flags maybe ?!?) ? Or how to reduce memory usage using static build ?
andre last edited by
How did you figure that you really use that much memory? Note that the loaded code (including libraries) is shared between your running instances. So, even though each instance reports that it uses 30MB, part of that 30MB for each of those processes is actually the same physical memory.
However, it seems weird to me to start 30-40 instances of the same application, including database features and all, on a single system. If you need a separate process to handle your USB, why don't you make just that part of the application a separate process, and control those processes from a single application with just one instance? That single application can then be responsible for the database connection, display of results, etc. You can have the processes communicate using a local socket or something like that.
mcosta last edited by
static build increase memory usage because you ave a copy of library in each instance.
I suggest you to split your application in a server/client architecture.
In this way you can havfe a single server application talking with ORACLE (with connection pool for example) and a client application for each USB connection.
However, as general rule, if more applications, or more instances of the same application, load the same DLL, it will be loaded once in memory. I think the memory used from your application depends to connection instances
Regarding share of loaded dlls in memory, based on data shown in VMMAP tool and ProcessExplorer, I don't think dlls are shared.
I'm aware that using same instance with full functionality has disadvantages, but also has advantage that if any of instace stops working it doesn't affect other instances. Solution with one server connected to DB and other instances as clients has big disadvantage if anything goes wrong with server, all clients are useless.
lgeyer last edited by
Is it possible that oraociei11.dll is indeed shared (static data and code) but each instantiation simply requires a certain amount of runtime memory (non-static data, heap and stack)?
If so, you may take a look at Oracle Instant if it allows for tweaking its memory usage (more likely) or using shared buffers and caches among instances (less likely).
If not, you are out of luck and you will have to create a dedicated server process to reduce memory usage (which sounds a reasonable idea in the first place, there are other ways to ensure reliability).