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
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 McDonaldkelly@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
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 Sedachvsedach@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 McDonaldkelly@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
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 McDonaldkelly@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 Sedachvsedach@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 McDonaldkelly@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net