Faster $RecursionLimit

[poke1024]

The currrent check for $RecursionLimit is slow for functions with recursion. For these cases, this PR yields a 20% improvement in performance.

This PR caches $RecursionLimit in an attribute of Definitions, thus avoiding having to look it up in the symbol tables. As the setting of $RecursionLimit already has special case inassignment.py, this change is easy. EDIT this turned out to be not true.

Before:

In[1]:= Timing[Length[#+1& /@ Range[10000]]]
Out[1]= {5.00666, 10000}

After:

In[2]:= Timing[Length[#+1& /@ Range[10000]]]
Out[2]= {4.08788, 10000}

Most other functions are not changed in their performance:

before.txt

after.txt

[sn6uv]

I wonder if there's a better way to do this. Is it actually the dictionary lookup that is slow? Could we just cache the Definition object for $RecursionLimit to avoid all the additional self.recursionlimit = None lines?

update: tried this but it didn't work. I'm guessing a new Definition object is being created.

[poke1024]

I don't completely understand why it takes so long, but I keep seeing lookup_name popping up in my performance profiles with quite big numbers and I suspect it has to do with the long chain needed to resolve a symbol, i.e.

Definitions.get_config_value()
which calls Definitions.get_definition()
which calls Definitions.lookup_name()
which calls Definitions.get_current_context()
which calls Definitions.get_ownvalue('System`$Context')
which calls Definitions.get_definition()
which calls Definitions.lookup_name()

I agree that the self.recursionlimit = None lines are ugly. Maybe I'll delegate them into an ownvalues_changed or something?

Again, probably this is not the right approach and $RecursionLimit is just the tip of the iceberg. The real problem might be that Definitions.get_definition() needs to be really fast. I looked at this code quite some time now, but it seems really hard to add some general caching there.

[poke1024]

I'm continuing this with a more generic approach in #507.