Mucking around with compilation

[Alan Ruttenberg]

So I made a pass at doing this cleanly. Please check out the changes at

https://github.com/alanruttenberg/abcl/commit/4e824ddd8f054eee4d943d0fdbbfcd83c17b26d7
 (precompiler.lisp, optimize-java-call.lisp)
https://github.com/alanruttenberg/abcl/commit/b46c704b1460ccd75035c3f590cdc52fff29886e
(test-optimize-java-call.lisp)

(second one has commit message with documentation)

It would be good to get one of the folks who have worked on the compiler to
see if I've done anything wrong. ABCL builds fine with this and I didn't
see any changes in the abcl.lisp tests.

For Mark, the test- file has this info but here it is again - 10000 calls
of (#"compile" 'regex.Pattern ".*")

With optimization: (INVOKE-RESTARGS-MACRO "compile" (QUOTE
REGEX.PATTERN) (LIST ".*") NIL T)
Without optimization: ((LAMBDA (#:G85648 &REST #:G85649)
(INVOKE-RESTARGS "compile" #:G85648 #:G85649 NIL)) (QUOTE
REGEX.PATTERN) ".*")

JUST-LOOP
0.0 seconds real time
0 cons cells

OPTIMIZED-JSS
0.011 seconds real time
0 cons cells

UNOPTIMIZED-JSS
0.325 seconds real time
800156 cons cells



On Thu, Oct 27, 2016 at 12:46 PM, Alan Ruttenberg <alanruttenberg at gmail.com>
wrote:

>
> On Thu, Oct 27, 2016 at 3:27 AM, Mark Evenson <evenson at panix.com> wrote:
>
>> Cool work!  What sort of efficiency gains do you expect for JSS here?
>>
>
> Not sure yet. The thing that actually drove it was that I didn't like
> seeing the redundancy in the stack traces when I was debugging. At first I
> played around with trimming them out of the stack trace but that ran in an
> issue - I couldn't figure out exactly how the indexing of stack frames was
> coordinated between emacs and lisp. Then it occurred to me that they didn't
> need to be there in the first place. So it's more of an aesthetic thing for
> now.
>
> Alan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20161104/12c85fbc/attachment.html>