jogamp › jogl

Disable debug logging

Classic

List

Threaded

6 messages Options

spectual

Disable debug logging

Hi

I can see with my profiler that jogl creates gabage (stringbuffers) which can be avoided by disabling debugging (some property it seems)

But how do i do that?

Regards
Klaus

Michael Bien

Re: Disable debug logging

can your profiler tell you where those stringbuffers came from? JOGL usually doesn't do any string concatenations by default.

On 10/10/2010 01:40 AM, spectual [via jogamp] wrote:

Hi

I can see with my profiler that jogl creates gabage (stringbuffers) which can be avoided by disabling debugging (some property it seems)

But how do i do that?

Regards
Klaus

View message @ http://jogamp.762907.n3.nabble.com/Disable-debug-logging-tp1672600p1672600.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

-- 
- - - -
http://michael-bien.com

spectual

Re: Disable debug logging

Hi Michael

I've might previously have misinterpreted the profiler, because it not quite the spot I thought.

The allocations seems to come from com.jogamp.nativewindow.impl.RecursiveToolkitLock line 112 (at least in my version).

The line is:

lockedStack = new Exception("Previously locked by "+owner+", lock: "+this);

So actually it is the Exception class which is making StringBuffer allocations, however that line is executed for each frame, which profiler also confirms since a lot of Exception objects is allocated too.

Sven Gothel

Re: Disable debug logging

Administrator

On Sunday, October 10, 2010 19:20:49 spectual [via jogamp] wrote:

>
> Hi Michael
>
> I've might previously have misinterpreted the profiler, because it not quite
> the spot I thought.
>
> The allocations seems to come from
> com.jogamp.nativewindow.impl.RecursiveToolkitLock line 112 (at least in my
> version).
>
> The line is:
>
> lockedStack = new Exception("Previously locked by "+owner+", lock: "+this);
>
> So actually it is the Exception class which is making StringBuffer
> allocations, however that line is executed for each frame, which profiler
> also confirms since a lot of Exception objects is allocated too.

Let me answer this, since this was my decision to add this code.
Reason: Better managed code, ie in case a timeout happens while waiting for a lock,
we have the convenience to see the culprit.

If these objects really allocate a lot of resources (time/memory),
we may change this to an optional behavior.

I may earmark this .. do you have numbers ?

Cheers, Sven

spectual

Re: Disable debug logging

Well timeouts should be a quite rare event, so I dont think offhand it justifies the overhead of this implementation.

Maybe it could be possible to achieve the same level of tracking without allocating anything? Perhaps by saving a reference to thread owning the lock (or maybe just the thread id or name), if it can be done safely without retaining the thread indefinitely.

I tried to make a rough estimate of the overhead. My test application runs at 60 fps. Every 2 seconds is allocated:

240 instances of java.lang.Exception
1200 instances of java.lang.String
3600 new chars

This sums of to approx. 10 mb. of garbage over 65 seconds.

It is propably an insignificant overhead for most applications, but considering it might never get a timeout, also mainly just a waste of resources :)

Sven Gothel

Re: Disable debug logging

Administrator

On Monday, October 11, 2010 20:00:35 spectual [via jogamp] wrote:

>
> Well timeouts should be a quite rare event, so I dont think offhand it
> justifies the overhead of this implementation.
>
> Maybe it could be possible to achieve the same level of tracking without
> allocating anything? Perhaps by saving a reference to thread owning the lock
> (or maybe just the thread id or name), if it can be done safely without
> retaining the thread indefinitely.
>
> I tried to make a rough estimate of the overhead. My test application runs
> at 60 fps. Every 2 seconds is allocated:
>
> 240 instances of java.lang.Exception
> 1200 instances of java.lang.String
> 3600 new chars
>
> This sums of to approx. 10 mb. of garbage over 65 seconds.
>
> It is propably an insignificant overhead for most applications, but
> considering it might never get a timeout, also mainly just a waste of
> resources :)

very good, great observation.

I agree, of course :)

will make the change in a bit, monitor the git repos (gluegen/jogl).

thx

Cheers, Sven