On Saturday, January 5, 2013 7:19:07 PM UTC+2, David Nolen wrote:
>
> On Sat, Jan 5, 2013 at 4:38 AM, Timo Westkämper
> <[email protected]<javascript:>
> > wrote:
>
>> Hi.
>>
>> I have some performance issues with a type inference I wrote in
>> core.logic. Here is the source code
>> https://github.com/timowest/symbol/blob/master/src/symbol/types.clj
>
>
> That's a neat bit of core.logic you have there :)
>
> It works quite well, but is too slow. I tried to profile it with VisualVM,
>> but as it has mostly anonymous functions, the results were difficult to
>> analyze.
>>
>> Based on a few changes I made I suspect that I need to optimize the
>> environment (the mapping of expressions to types) handling somehow.
>
>
>
> Are there good alternatives to cons/lcons based handling of mappings in
>> core.logic? Also if you have any general core.logic performance improvement
>> tips, I'd like to hear them.
>>
>
> Yes encoding an environment as a list is not optimal. It may be possible
> to do this properly with persistent maps via constraints. I've been a bit
> too busy w/ fixing up bugs for a proper core.logic 0.8.0 release to pursue
> this avenue myself. But it would look something like this:
>
> (assoc m k0 v0 newm)
> (getc newm k0 v1)
>
Are there or will there be goals to do this in core.logic? Having direct
support for maps would be great.
>
> Hopefully that makes some sense. One thought that just jumped into mind -
> have you considered making your own lookupo that using tabling so you can
> cache the results of the type environment lookup?
>
Ok, I could try that.
>
>
>> I also noticed that with big environments, I easily get
>> StackOverflowErrors, any ideas how to avoid them?
>>
>
> A gist that includes an example plus the stacktrace would be very
> informative. This might be a simple one to fix.
>
Here is one example
(def l (range 0 2000))
(run* [q] (appendo l l q))
StackOverflowError
clojure.lang.PersistentHashMap$ArrayNode.find
(PersistentHashMap.java:370)
clojure.lang.PersistentHashMap$ArrayNode.find
(PersistentHashMap.java:370)
>
>
>> Best regards,
>> Timo
>
>
> This is one of the more ambitious core.logic programs I've seen. Some
> examples that I could try myself would be helpful to understand the issues.
>
Ok, I will try if I can extract one of those SO errors.
I also noticed that I could get significant performance gains when encoding
certain goal usage patterns more directly like this
(defna argso
[bindings args]
([[?k ?v] [?k]])
([[?k1 ?v1 ?k2 ?v2] [?k1 ?k2]])
([[?k1 ?v1 ?k2 ?v2 ?k3 ?v3] [?k1 ?k2 ?k3]])
([[?k ?v . ?rest] [?k . ?resta]]
(argso ?rest ?resta))
([[] []]))
I suspect this means that the recursion in goals is not yet as performant
as it could/should be?
Br,
Timo
>
> David
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
