Suddenly I detect that my application is using too much memory, so I need some way to know how much memory is used by some object to improve the app. How can I do it?
I've used some OS specific things but they aren't convenient because provide information about the whole application, instead of the specific class instance. Simple size calculation of class fields doesn't correspond to memory consumption.

Alexandr Druzhinin:

> so I need some way to know how much memory is used by some object to improve the app. How can I do it?

> I've used some OS specific things but they aren't convenient because provide information about the whole application, instead of the specific class instance. Simple size calculation of class fields doesn't correspond to memory consumption.

Try:
http://dlang.org/traits.html#classInstanceSize

Also, the GC has some useful hooks.

Bye,
bearophile

18.02.2013 20:54, bearophile пишет:
> Alexandr Druzhinin:
>
>> so I need some way to know how much memory is used by some object to
>> improve the app. How can I do it?
>
>> I've used some OS specific things but they aren't convenient because
>> provide information about the whole application, instead of the
>> specific class instance. Simple size calculation of class fields
>> doesn't correspond to memory consumption.
>
> Try:
> http://dlang.org/traits.html#classInstanceSize
>
> Also, the GC has some useful hooks.
>
> Bye,
> bearophile

Thanks a lot!
Also, what hooks do you mean? I look at core.memory and don't see anything like hooks... I'd appreciate this information.

On 2013-02-18 13:43, Alexandr Druzhinin wrote:
> Suddenly I detect that my application is using too much memory, so I
> need some way to know how much memory is used by some object to improve
> the app. How can I do it?
> I've used some OS specific things but they aren't convenient because
> provide information about the whole application, instead of the specific
> class instance. Simple size calculation of class fields doesn't
> correspond to memory consumption.

An object will contain some hidden members as well. Try this:

http://dlang.org/traits.html#classInstanceSize

-- 
/Jacob Carlborg

18.02.2013 21:23, Jacob Carlborg пишет:
> An object will contain some hidden members as well.
I agree. But hidden member can't occupy so much memory that I disturb so much. I'm sure I use memory allocation in wrong manner but I haven't glue so far.
Manual memory allocating is simpler for me than gc - I mean it's more explicit.

On 2013-02-18 15:53, Alexandr Druzhinin wrote:

> I agree. But hidden member can't occupy so much memory that I disturb so
> much. I'm sure I use memory allocation in wrong manner but I haven't
> glue so far.
> Manual memory allocating is simpler for me than gc - I mean it's more
> explicit.

Some things to take into consideration:

* The GC will always allocate in chunks and may therefore use more than expected memory

* The GC will never give back memory to the OS which it has allocated

-- 
/Jacob Carlborg

18.02.2013 22:39, Jacob Carlborg пишет:
>
> * The GC will never give back memory to the OS which it has allocated
>
and this the next problem I get - the application eats memory always. in C++ I'd say it is leaks but with gc I'm not sure it is - I guess gc collects memory but I don't see in reality. I think I don't understand something important and now I read from the start.

On Mon, Feb 18, 2013 at 11:13:25PM +0700, Alexandr Druzhinin wrote:
> 18.02.2013 22:39, Jacob Carlborg пишет:
> >
> >* The GC will never give back memory to the OS which it has allocated
[...]

Take a look at GC.minimize() here:
http://dlang.org/phobos/core_memory.html

Or does that not work at the moment?


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

On 02/18/2013 08:13 AM, Alexandr Druzhinin wrote:
> 18.02.2013 22:39, Jacob Carlborg пишет:
>>
>> * The GC will never give back memory to the OS which it has allocated
>>
> and this the next problem I get - the application eats memory always. in
> C++ I'd say it is leaks but with gc I'm not sure it is - I guess gc
> collects memory but I don't see in reality. I think I don't understand
> something important and now I read from the start.

Try to build as a 64-bit application. If it helps, you may be seeing the effects of the current GC implementation being conservative.

Ali

On 2013-02-18 17:13, Alexandr Druzhinin wrote:

> and this the next problem I get - the application eats memory always. in
> C++ I'd say it is leaks but with gc I'm not sure it is - I guess gc
> collects memory but I don't see in reality. I think I don't understand
> something important and now I read from the start.

The GC works like this:

1. Request memory
2. No memory is available
3. Run a collect cycle
4. If memory still isn't available allocate more from the OS

When it runs a collect it will keep the memory so it can used it for future allocations instead of give it back to the OS.

-- 
/Jacob Carlborg