Reuse Split without producing garbage

14 views
Skip to first unread message

Hari

unread,
Jun 3, 2014, 7:59:26 AM6/3/14
to java...@googlegroups.com
I just came across this project and from the functionality, it looks like exactly what I need. However, I noticed that interface is very heavy as it creates a Split object for every measurement, thus creating a lot of garbage for tight loops. The Split.start() seemed promising, until I looked at the code and noticed that it too creates a new Split instance. IMHO, there should be a way to just reuse a Split or some other instance such that a thread can keep reusing it safely, as long as it is not being shared with any other thread. Any thoughts on this idea?

Richard Richter

unread,
Jun 3, 2014, 8:38:02 AM6/3/14
to java...@googlegroups.com
Hi Hari

Split was designed to work in multi-threaded environment, that's why
it is created for every stopwatch.start(). Original design used
internal thread local map that was proof to memory-leak, etc. This is
actually much lighter and more safe - if you forget about split, it
will get GCed. Split is not build for multiple measurements.

Technically there would be way how to reuse single split for more
measurements, some kind of restart method. I tried to experiment with
the idea and I see no problem to add it there, however it will appear
not sooner than 4.0 release (min req. Java SE 7), probably within a
couple of months.

As of now, if you need Simon for other features, I recommend using
some tool of yours and adding it to Stopwatch - HOWEVER, the only way
is addSplit(Split), which comes back to the "very heavy" Split.
Generally Split (a single object, not really that heavy) is not a
problem, but it is not recommended to do tons of measurements in tight
loops anyway. With restart this would be a little bit lighter, but
still not recommended. Calls to timers take long time on its own
anyway, much longer than the rest of Simon's stuff.

Cheers

Virgo
> --
> You received this message because you are subscribed to the Google Groups
> "javasimon" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to javasimon+...@googlegroups.com.
> To post to this group, send email to java...@googlegroups.com.
> Visit this group at http://groups.google.com/group/javasimon.
> For more options, visit https://groups.google.com/d/optout.

Hari

unread,
Jun 4, 2014, 7:22:11 AM6/4/14
to java...@googlegroups.com
Thanks for the response. Yes, some kind of restart() is what I had in mind, so that the instance can be reused within the same thread. I will look forward to the 4.0 release with this change.

You are right that you wouldn't want to use this inside tight loops in production code, but while doing benchmarking, this could come handy (instead of a simple approach based on capturing start and end timestamp).

Hari

unread,
Jun 11, 2014, 10:52:48 AM6/11/14
to java...@googlegroups.com
BTW, I missed to see the StopWatch.addTime(long ns), so wondering if this could be used as a lighter-weight alternative. Looking at the source code for StopWatchImpl.addTime(), I can see that it still constructs a new sample, but only if there is a callback registered. By stepping through the code, I noticed that there was no callback registered, so it seems like a very lightweight call. However, I am not sure what Simon configuration could end up getting these callbacks added.

BTW, in StopWatchImpl.addTime(), if manager.callback().callbacks().isEmpty(), there is no sample constructed, but the manager.callback().onStopwatchAdd is still called. This is right now harmless, but the call should probably be protected with a non-null on sample, unless callbacks are expected to handle a null sample as a contract.

Richard Richter

unread,
Jun 11, 2014, 6:23:37 PM6/11/14
to java...@googlegroups.com
I'm not sure this method is available anymore, it was merged with
addSplit, hence is not that lightweight anymore. There were some
reasons for merge, especially because of callbacks. I can't check the
code right now, but I'm quite convinced that addTime is not in current
version. If I'm mistaken, just disregard this email. ;-)

Virgo

Hari Krishna Dara

unread,
Jun 11, 2014, 11:45:44 PM6/11/14
to java...@googlegroups.com
I am stuck with 3.3.0 right now, so I will keep this in mind for the time when I can upgrade. I can see from the latest code that addTime() is missing, so you are right:




You received this message because you are subscribed to a topic in the Google Groups "javasimon" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/javasimon/MrA6bNpUx4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to javasimon+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages