Re: optimizeit: how to workaround/minimize wrong cput time in Object.wait()

From: Robert Klemme (bob.news_at_gmx.net)
Date: 11/10/04

  • Next message: Cathy Arima: "Online chat: NetBeans 4.1 IDE Early Access" 
    Date: Wed, 10 Nov 2004 16:31:52 +0100

    "NOBODY" <antispam@0.0.0.0> schrieb im Newsbeitrag
    news:Xns959D57C4C9C71nobodyantispam@207.35.177.135...
    > It is definitly an optimizeit limitation.
    > OI 6 gives the same ***.
    > Jprobe doesn't.
    > The weird YourKitProfiler doesn't.
    > I will try good old fashion sun's hprof today (just because this one is
    > free... and may be more of a reference...)

    I'm quite satisfied with that for profiling. Avoids the overhead of a GUI
    applciation and breaks only rarely. :-)

    > >Then are you satisfied with the throughput?
    > No. And I'm just trying to apply the 80%-20% rule.
    > Once optimized, I should see code in the hotspots, not wait()!
    > I have never seen that before, ever, in 6 years.
    > Modern pc's are probably too fast for optimizeit approach of profiling.
    > Note that in instrumentation mode, OI gave me substackframes under wait
    > ()!
    > Like wait called my other methods! (probably those methods that ran
    > between the 2 wait)... I want my money back! hehehe!

    You won't - not after 6 years. ;-)

    > > I did a small test where I increased overall wait time by sleeping
    > > before the notify and wait didn't even show up in the profiler results
    > > (with -Xrunhprof). Probably testing another profiler is best you can
    > > do at the moment.
    >
    > You have to notify more, not less.
    > You want to cause the waiting thread wait to exit, do a quick job and go
    > back to wait, so that the OI profiler thinks no other method/line of
    code
    > was running but thread was not blocked.

    That's basically what my program did (there were a lot wait-notify cycles)
    only that I artifically increased the time between two notifies. The code
    between wait wakeup and next wait is essentially a for loop with int
    increment => fast. Even reducing the period between two notifies didn't
    make wait() show up in the profiler output.

    > > Since this seems to affect only one place in the code, did you
    > > consider instrumenting the code with measurements of your own? You
    > > could have a wait counter and a wait time counter and thus determine
    > > average wait time.
    >
    > System.currentTimeMillis is only ms, not nanoseconds...!

    That might be sufficient or not - that depends on your scenario. If
    workers wait most of the time, then they might wait longer than 1 ms. You
    could also round up 0ms to 1ms (or 10ns) to avoid 0.

    > Allright, Thanks Robert.
    > I will report a bug to borland... if at all possible...
    > Have a good week.

    Have fun!

        robert

  • Next message: Cathy Arima: "Online chat: NetBeans 4.1 IDE Early Access"
    • Quantcast