<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Tahoma">Hi<br>
      <br>
      Is there a way of getting a stacktrace from this tool, so we could
      see where the /proc/self/map access is coming from?<br>
      <br>
      Regards, Noel.<br>
    </font><br>
    Michael Meeks wrote:
    <blockquote cite="mid:1319036866.5425.321.camel@lenovo-w500"
      type="cite">
      <pre wrap="">
On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02 seconds that alone would account for some 4 minutes of the run.
</pre>
        </blockquote>
        <pre wrap="">
7321 times reading out /proc/self/map -- no idea why it does that, but 
that clearly ain't no good...
</pre>
      </blockquote>
      <pre wrap="">
        Yep :-) If I remember rightly - the only moving part in this
side-to-side performance comparison that causes a substantial decrease
in performance is Java 7 vs 6 right ? The strace shows it poking
at /proc/self/map endlessly (something that is not done by any
LibreOffice code I can find off hand), which perhaps helps isolate the
problem rather better ?

        Ideally of course, we would have a native SQLite database to avoid
needing to use that hsqldb thing (as you do) - potentially it is
provoking java performance problems by using a method call that used to
be fast but is now slow; or ... ?

        So - it's not clear what best to do about this really,

        Is there a good java profiler out there we could use on a mixed C++ /
Java process like ours ?

        Thanks,

                Michael.        

</pre>
    </blockquote>
  <br><br><br><hr><font size="-2" color=808080>Disclaimer: <a href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a><br><br>

</body>
</html>