<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Erik,<br><br>Thank you for your reply! Sorry for confusing subject-line and the brief initial message; here are more details:<br><br>I'm using ABCL as a JSR-223 scripting language for the Electric VLSI system. To access the Electric's Java-classes I have a hacked-up version of JFLI, conveniently allowing me to say eg <br><blockquote type="cite">(def-java-class "com.sun.electric.database.network.Netlist")<br></blockquote>to get wrappers for the Java-members of that class. The JFLI-magic obviously happens by introspection (JCLASS-METHODS), basically generating a ton of (lazy) member-wrapping functions.<br><br>As I watch the embedded ABCL compile a file #p"tool.lisp" of such DEF-JAVA-CLASS statements, it immediately spits out hundreds of temporary cls-files and a abcl-file,<br><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1790 Aug 24 08:04 ASDF_TMP_tool_9.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1800 Aug 24 08:04 ASDF_TMP_tool_8.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1787 Aug 24 08:04 ASDF_TMP_tool_7.cls<br></blockquote><blockquote type="cite">(...)<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1254 Aug 24 08:04 ASDF_TMP_tool_244.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1359 Aug 24 08:04 ASDF_TMP_tool_243.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1248 Aug 24 08:04 ASDF_TMP_tool_242.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff    1362 Aug 24 08:04 ASDF_TMP_tool_241.cls<br></blockquote><blockquote type="cite">-rw-r--r--  1 mrohne  staff  108500 Aug 24 08:04 ASDF-TMP-tool.abcl<br></blockquote>then goes on chewing on those files for quite a while. Eventually it removes the cls-files and (I assume) renames ASDF-TMP-tool.abcl to tool.abcl. The chewing-time grows non-linearly with the number of cls-files, which in turn seems to depend on the "size" of the Java-class being wrapped, hence my confusing subject-line. A few hundred cls-files finishes in minutes, while more than a thousand easily takes the full morning. A few months back ABCL behaved quite differently, compiling many tens of  JFLI-imported classes in a few minutes, so I'm wondering what might have changed?<br><br>Ole<br><br>On 2011-08-23, at 16:39 , Erik Huelsmann wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Ole,<br><br><div class="gmail_quote">On Tue, Aug 23, 2011 at 2:54 PM, Ole Myren Rohne <span dir="ltr"><<a href="mailto:ole.rohne@free.fr">ole.rohne@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi ABCL-developers,<br>
<br>
Is there a recent change (since May?) that would have made compiling files containing large wrapped Java-classes excessively slow? If so, is there any hope of this eventually improving?<br><br></blockquote><div><br></div>
<div>Do you have an example of what you're referring to? I'm affraid I'm not fully understanding what you're trying to do. If there's an obvious performance problem, I sure hope we can do something about it. We do not normally accept performance regressions outside our own build times.</div>
<div><br></div><div>That said, I've only seen build and runtimes improve over the last years (I mainly test with the compilation of Maxima, though).</div><div><br></div><div><br></div><div>Bye,</div><div><br></div><div>
<br></div><div>Erik.</div></div><br>
</blockquote></div><br></body></html>