[parenscript-devel] long compile time

[Vladimir Sedach]

Hi Kelly,

Did you try it with the latest version from the repository? The patch
I committed makes 'ps' and 'ps*' use the same mechanism for
concatenating strings, which means that in your use case 'ps' should
be faster than 'ps*', since it does all of the compilation at
macro-expansion time (I've confirmed this with some ad-hoc
benchmarks).

Which Lisp implementation are you using? Are you compiling the files?
One thing I can think of that might affect speed is if you're using an
implementation like CLISP which has an interpreter - that might affect
how often 'ps' gets macro-expanded.

Vladimir

On Mon, Jul 6, 2009 at 2:54 PM, Kelly McDonald<kelly at fammcdonald.net> wrote:
> Vladimir,
>
> Thanks for your response.
>
> I thought I had posted back to the list, but I don't find my message.
>
> If I use instead
> (defun foo ()
>       (ps* '(lots of parenscript)))
>
> Everything works as it used to. In my context there is no difference
> in results between  (ps (form)) & (ps* '(form))
>
> except for the time issue that is . . .
>
> Thanks again,
> Kelly
>
> On Mon, Jul 6, 2009 at 4:16 PM, Vladimir Sedach<vsedach at gmail.com> wrote:
>> Hi Kelly,
>>
>> First of all, apologies for taking so long to respond.
>>
>> The blame for this goes to my ignorance of how to do fast string
>> concatenation in Common Lisp. The 'ps' macro expanded into a
>> 'concatenate' form, which was slow. Right now I changed it (just
>> pushed the patch) to expand into a 'with-output-to-string' and a bunch
>> of 'write-string' forms, which is about twice as fast on SBCL 1.0.22
>> and conses a little less.
>>
>> If anyone knows of an even faster way, please let me know.
>>
>> Thanks,
>> Vladimir
>>
>> On Wed, Jun 24, 2009 at 2:23 PM, Kelly McDonald<kelly at fammcdonald.net> wrote:
>>> Hello, I'm sure I'm doing something dumb, I just need someone to set
>>> me straight.
>>>
>>> I recently updated to the latest parenscript (as well as sbcl) and got
>>> all of the errors for where I had  this.dropdownlist.length type
>>> notation
>>> and changed it to (@ this dropdownlist length) notation.
>>>
>>> I had something that used to compile rather quickly it was as simple as this:
>>>
>>> (defun somefunction ()
>>>  (ps
>>>        (very long parenscript code)))
>>>
>>> if I evaluate just the (ps (very long parenscript code))  everything
>>> is really snappy & I get what I expect.
>>>
>>> if I evaluate the whole function, it takes forever (ok, like 10
>>> minutes) again, once things evaluate, I get what I expect
>>>
>>> Furthermore, if I start small and add stuff in, it seems to take
>>> exponential time to the amount of code (or more likely my patience
>>> gets exponentially shorter)
>>>
>>> the same thing happens if I merely do a (setf somevar (ps (very long
>>> parenscript code)))
>>>
>>> I'm suspecting that I'm hitting some kind of compiler optimization and
>>> I need some kind of pragma.
>>>
>>> Thanks for your thoughts/suggestions,
>>> Kelly McDonald
>>>
>>> _______________________________________________
>>> parenscript-devel mailing list
>>> parenscript-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>>
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>