Lee_Nover
asked on
running code from a dll as a new process
I have two apps:
- VideoServer - a standalone video survailance app
- ServerGuard - manages the servers and runs them
the server is always in one location, only the settings for it change for every new instance
the guard also provides a crash-recover mechanism for the server
if the server freezes or terminates unexpectedly the guard has an option to rerun the server
if the server freezes then the guard terminates the servers process !
for now I have the server as an exe
the guard can run as many servers as it 'wants'
so every server takes it's memory toll
I've already built all of the projects in the group with RT packages
that reduced memory consumption of the server from 38 to 22 mb :)
but still if you have 4 cameras running that's almost 100 mb !!!
I'd like to create a dll from it so the core functions would be shared
that's not really a problem
the problem is that I need a process handle for the guard !!
so how could I run some dll code as a separate process ??
if it turns out difficult I'll increase the points
I have about 2000 to spare :)
- VideoServer - a standalone video survailance app
- ServerGuard - manages the servers and runs them
the server is always in one location, only the settings for it change for every new instance
the guard also provides a crash-recover mechanism for the server
if the server freezes or terminates unexpectedly the guard has an option to rerun the server
if the server freezes then the guard terminates the servers process !
for now I have the server as an exe
the guard can run as many servers as it 'wants'
so every server takes it's memory toll
I've already built all of the projects in the group with RT packages
that reduced memory consumption of the server from 38 to 22 mb :)
but still if you have 4 cameras running that's almost 100 mb !!!
I'd like to create a dll from it so the core functions would be shared
that's not really a problem
the problem is that I need a process handle for the guard !!
so how could I run some dll code as a separate process ??
if it turns out difficult I'll increase the points
I have about 2000 to spare :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
kretzschmar
listening . . .
ASKER
333 good idea :)
I never thought of it :)
I'll wait a while for other ideas if anyone has any
I'll also try your method for now
I never thought of it :)
I'll wait a while for other ideas if anyone has any
I'll also try your method for now
ASKER
oh .. a typo
that was from 28 to 22 mb memory usage ! :)
hum ... about running such an application where the actuall app stuff is in a dll
should I use:
with Application do
begin
Initialize;
CreateMainFormFromDll;
MainForm.ShowModal;
Run;
end;
actually I don't even need the application object here
simply:
begin
CreateMainFormFromDll;
MainForm.ShowModal;
end.
or any other method ?
that was from 28 to 22 mb memory usage ! :)
hum ... about running such an application where the actuall app stuff is in a dll
should I use:
with Application do
begin
Initialize;
CreateMainFormFromDll;
MainForm.ShowModal;
Run;
end;
actually I don't even need the application object here
simply:
begin
CreateMainFormFromDll;
MainForm.ShowModal;
end.
or any other method ?
question about your app (maybe you won't be able to reduce memory with dll): those 22mb are your exe's size :) or memory allocated to for example video buffers etc.?
if you can share the same buffers along different server instances, then you can reduce memory usage, otherwise you can't. also, if you create the same component (form or whatever) for each instance, this won't reduce memory usage, if you can create component once and it will work with different server instances, then your memory will be reduced.
sometimes you won't get any benefit from using dlls vs exes. the point is, that when you run your exe first time, windows loads exe's code and data segments into memory, when you run second instance of the same exe, code segment isn't loaded into memory, only pointer will be returned to first instance's code. however, any variables and buffers will be created. so the code part of your app is acctualy shared and it's similar to dlls. exeption to this is compressed exes, for example with upx. in this case, each instance's code will be loaded into memory and it will not be shared and this will increase memory usage.
you may benefit from dll if you're able to use shared memory. when you have separate exes, your code is shared, but data - not. using dll is posible to create objects and allocate buffers once and then share them among instances.
so, if the biggest part of memory is allocated to for example video buffers and you can read or write from different instances to the same buffer, go for dll.
if you can share the same buffers along different server instances, then you can reduce memory usage, otherwise you can't. also, if you create the same component (form or whatever) for each instance, this won't reduce memory usage, if you can create component once and it will work with different server instances, then your memory will be reduced.
sometimes you won't get any benefit from using dlls vs exes. the point is, that when you run your exe first time, windows loads exe's code and data segments into memory, when you run second instance of the same exe, code segment isn't loaded into memory, only pointer will be returned to first instance's code. however, any variables and buffers will be created. so the code part of your app is acctualy shared and it's similar to dlls. exeption to this is compressed exes, for example with upx. in this case, each instance's code will be loaded into memory and it will not be shared and this will increase memory usage.
you may benefit from dll if you're able to use shared memory. when you have separate exes, your code is shared, but data - not. using dll is posible to create objects and allocate buffers once and then share them among instances.
so, if the biggest part of memory is allocated to for example video buffers and you can read or write from different instances to the same buffer, go for dll.
ASKER
tnx for the info :)
didn't know exes code was shared !
I don't compress the server exactly because of that non-sharing thingie (I knew about that :)
with using RT packages there is also no need to compress them :)
I have some buffers but they can't be shared
I also have lots of helper functions and I was thinking of moving those to a dll
so if I understood you correctly that code would be shared in memory with an exe as well .. or am I wrong ?
the biggest memory eater are the resources I think
using ks theme for 'leet' xp looks :) (the boss wanted that)
which reminds me .. gotta move that into a RT package also :)
didn't know exes code was shared !
I don't compress the server exactly because of that non-sharing thingie (I knew about that :)
with using RT packages there is also no need to compress them :)
I have some buffers but they can't be shared
I also have lots of helper functions and I was thinking of moving those to a dll
so if I understood you correctly that code would be shared in memory with an exe as well .. or am I wrong ?
the biggest memory eater are the resources I think
using ks theme for 'leet' xp looks :) (the boss wanted that)
which reminds me .. gotta move that into a RT package also :)
about code sharing you may read this
http://www.jrsoftware.org/striprlc.php#execomp
not much info but....
well, most of your functions code should be shared (at least i don't know why the should not :)
i don't know what your server does and how it looks, but AFAIK most servers are running as services or console apps or programs with simple hidden windows, to decrease resource consumption. if you're using gui for some administrative tasks (like setting up parameters etc), then you may consider to make this gui as separate exe, with ability to connect to different servers and talk to them using named pipes for example. in this case, your form with lots of funky bitmaps and other resource eaters will be launched only once.
http://www.jrsoftware.org/striprlc.php#execomp
not much info but....
well, most of your functions code should be shared (at least i don't know why the should not :)
i don't know what your server does and how it looks, but AFAIK most servers are running as services or console apps or programs with simple hidden windows, to decrease resource consumption. if you're using gui for some administrative tasks (like setting up parameters etc), then you may consider to make this gui as separate exe, with ability to connect to different servers and talk to them using named pipes for example. in this case, your form with lots of funky bitmaps and other resource eaters will be launched only once.
ASKER
yes I already separated all of the settings gui and info guis from the main app
they're created dinamically but still in the same app
that should be enough I guess :)
my server is a complete standalone VideoSurvailance app
but I'll split it into parts as needed
they're created dinamically but still in the same app
that should be enough I guess :)
my server is a complete standalone VideoSurvailance app
but I'll split it into parts as needed
ASKER
uh .. forgot to say that other forms have to be in the app because they're bound to some datasets in the main form