<div dir="ltr">Well, clearly whatever your code is spending most of its time doing is pretty slow in CCL. In my experience when that kind of a huge discrepancy occurs, it can be corrected (e.g. to bring implementations to within an order of magnitude of each other) fairly easily once you know what's causing it. Do you have any profiling results (from any of the implementations -- lispworks might be the easiest) to indicate where you spend most time?<div><br></div><div><br><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 5:44 PM, Craig Lanning <span dir="ltr"><<a href="mailto:craig.t.lanning@gmail.com" target="_blank">craig.t.lanning@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been working on a rather large application that runs from the<br>
command line. It reads schema files that are part of the ISO 10303<br>
STEP family of product data standards. It can also read the<br>
corresponding Product Data Population files.<br>
<br>
Recently someone gave me a script that runs a schema comparison (using<br>
my application) across several schemata. (In this case, the script<br>
processed 17 schema pairs.) The act of processing one pair of schema<br>
files will mean that additional schema files are pulled from a special<br>
repository. The schema files being processed "include" other schema<br>
files which also may "include" even more schema files.<br>
<br>
I can build my application using LispWorks CL 6.1.1, Clozure CL v1.11,<br>
and SBCL 1.3.16.<br>
<br>
I can build with LispWorks CL 6.1.1 in 32-bit only.<br>
<br>
I can build with Clozure CL 1.11 in both 32-bit and 64-bit.<br>
<br>
I can build with SBCL 1.3.16 in 64-bit only. (No easy way to get both<br>
the 32-bit and 64-bit versions at the same time.)<br>
<br>
The source code for my application is stored on SourceForge<br>
(<a href="http://exp-engine.sourceforge.net/" rel="noreferrer" target="_blank">http://exp-engine.<wbr>sourceforge.net/</a>) as the original development was<br>
intended to be an open source project.<br>
<br>
LWL 6.1.1(32) SBCL 1.3.16(64) CCL 1.11(32) CCL 1.11(64)<br>
App Compile 10.323 sec 18.002 sec 10.242 sec 10.587 sec<br>
App Deliver 4.306 sec 6.379 sec 1.418 sec 1.875 sec<br>
App Filesize 37,429,248 57,<wbr>409,584 24,719,376 <wbr>33,460,464<br>
17 schemata 8.320 sec 7.506 sec 23:49.054 23:<wbr>44.190<br>
<br>
The machine used was<br>
Dell Inspiron 3558 Laptop<br>
Intel Core i3 2.1GHz CPU<br>
4GB Memory<br>
<br>
As you can see in the chart above, CCL 1.11 took over 23 minutes to<br>
process the 17 schema pairs. Not a good showing.<br>
<br>
This application does not allocate and deallocate large amounts of<br>
memory so I have no information about which Lisp handles memory the<br>
best. None of the Lisps tested ran out of memory.<br>
<br>
LispWorks and Clozure CL both start with a small amount of memory and <br>
grow and shrink the dynamic space as needed so I suspect that they<br>
handle memory the best.<br>
<br>
SBCL needs to be told what its maximum dynamic space size is. It then<br>
allocates all of that memory.<br>
<br>
My purpose in posting this message was to give a reference for how<br>
different Lisps support real applications.<br>
<br>
I was curious about whether CCL's time has improved in successive<br>
releases so I downloaded CCL 1.10 and 1.9. I was unable to run 1.9,<br>
but was able to run 1.10. 1.11 produced a slower executable than 1.10.<br>
<span class="HOEnZb"><font color="#888888"><br>
Craig Lanning<br>
______________________________<wbr>_________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
<a href="https://lists.clozure.com/mailman/listinfo/openmcl-devel" rel="noreferrer" target="_blank">https://lists.clozure.com/<wbr>mailman/listinfo/openmcl-devel</a><br>
</font></span></blockquote></div><br></div>