<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Whoops - forgot the link:</p>
    <p>[1] -
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/11787810/strlen-performance-implementation">https://stackoverflow.com/questions/11787810/strlen-performance-implementation</a><br>
    </p>
    <div class="moz-cite-prefix">On 24/03/2023 21:22, Maurizio
      Cimadamore wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:318e5773-060f-410a-8e97-29285d5527e4@oracle.com">
      
      <p>Hi Glavo,<br>
        that's a very interesting comparison, thank you!</p>
      <p>We will look into the C string -> Java string issue. There
        are probably "tricks" [1] that native strlen does which we could
        replicate in our Java code (or we could just do a trivial call
        to strlen :-) ).</p>
      <p>Aso for struct layouts, I think it is a reasonable request -
        e.g. allow creation of struct layouts which are "padded"
        correctly. But I think we'd still want to retain the "raw"
        variant, which might be useful for tools such as jextract.</p>
      <p>Cheers<br>
        Maurizio<br>
      </p>
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 24/03/2023 19:07, Glavo wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:CAJL5A3=E+1pD7AKffx7pSMksq6jGWhL8B39XidPbO0+b8MW8zg@mail.gmail.com">
        <div dir="ltr">I have run a series of benchmarks of Panama, JNI,
          JNA, and JNR based on the latest JDK. Here is its GitHub
          repository:<br>
          <div><br>
          </div>
          <div>    <a href="https://github.com/Glavo/java-ffi-benchmark" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/Glavo/java-ffi-benchmark</a></div>
          <div><br>
          </div>
          <div>Here I tested the performance of no-ops, accessing
            structs, string conversions, and callbacks, respectively. I
            also tried the new isTrivial linker option.</div>
          <div>I summarized the results in README and charted them.<br>
          </div>
          <div><br>
          </div>
          <div>In this email, in addition to sharing the above results,
            I would also like to talk about several issues I have
            encountered<br>
          </div>
          <div><br>
          </div>
          <div>1. MemorySegment.getUtf8String is unexpectedly slow</div>
          <div><br>
          </div>
          <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
            <div>Panama is much faster than JNA in most cases, but the
              operation of converting C strings to Java strings is an
              exception.</div>
            <div>I checked the source code of JNA and Panama, and the
              suspicious difference is that JNA uses strlen from the C
              standard library, while Panama uses Java loops. </div>
            <div>Perhaps this method can be optimized.</div>
          </blockquote>
          <div><br>
          </div>
          <div>2. StructLayout must manually specify all padding</div>
          <div><br>
          </div>
          <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
            <div>Can we provide a convenient method for automatically
              padding between fields based on alignment?</div>
            <div>The current structLayout method is annoying for
              situations where you need to manually simulate the layout
              of a C struct.</div>
          </blockquote>
          <div><br>
          </div>
          <div>Glavo</div>
        </div>
      </blockquote>
    </blockquote>
  </body>
</html>