[Mono-dev] Fwd: [Mono-list] Per-process memory overhead
chmorgan at gmail.com
Sat Sep 6 00:03:55 UTC 2014
Posting to the devel list to see if anyone has any other ideas. I'd love to
get the overhead of these processes down rather than be worried about
running out of memory or having to rewrite code in c/c++...
On Sun, Aug 31, 2014 at 10:26 AM, Agustin Gimenez <geniwab at gmail.com> wrote:
> Hi Chris.
> .net and mono always have some overhead, so I think it's normal.
> Instead of creating a dozen of processes, why don't you create just one
> and as many buses as you need inside that process?
The thought crossed my mind to do that. It isn't the simplest approach
though but it would work. If it works then its suitable if say 12 of these
bridges would fit inside of a single 14MB process. If not then I'll end up
having to reimplement in c and I'd prefer not to go that route.
Is ~14MB really the overhead I should be expecting per-process? I haven't
tried mono 3.6 yet but nothing in the release notes indicated a large
memory overhead savings.
> El 31/08/2014 02:52, "Chris Morgan" <chmorgan at gmail.com> escribió:
>> I'm looking to use mono for some dbus bridges with dbus-sharp. I've got a
>> pretty simple bridge, a couple of classes and a single dbus interface that
>> bridges to a socket in a console application. It looks like each instance
>> has ~14MB of memory overhead, from smem output:
>> 30038 cmorgan mono display_interface.exe 0 16792 19650
>> So, 16.7MB USS, 19.65MB PSS and 23.48MB RSS.
>> Using mono 3.4 on Fedora 20.
>> I ran the alloc profiler on the application and it looks like there was
>> some 700k of memory allocated in the application itself, quite small
>> compared to the process memory.
>> I'd like to be able to use mono to create a dozen or more of these dbus
>> bridges but the embedded arm system I'm using only has 512MB of ram.
>> I haven't tested on the arm platform yet, but I'm assuming a similar
>> amount of overhead for each process.
>> Is this a normal amount of overhead per-process? Thoughts on how I might
>> be able to reduce it?
>> Mono-list maillist - Mono-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list