On Sat, Jan 5, 2013 at 4:38 AM, Timo Westkämper <[email protected]>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) 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? > 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. > 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. 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
