Using __slots__ for classes which are critical in performance

[mmatera]

One idea I had some time ago by looking at other Python projects is to consider using __slots__ to define the set of attributes of classes like Definitions, BuiltinRule or Expression. It seems that this could help to save a lot of memory and also makes the access to these attributes a little bit faster (~5% - 10%).

Here I started a branch implementing this change in Definitions and Definition. Comparing against master, it seems to be ~10% faster in building and accessing Definitions.

from mathics.session import MathicsSession
import mathics


session=MathicsSession()
session.evaluate("Unprotect[Plus]")
session.evaluate("Plus[Q[x_],S[y_]]:=37")


import random  
import string  

cache_random_names = []
for i in range(10000000):
    result = ''.join((random.choice(string.ascii_lowercase) for x in range(6))) 
    cache_random_names.append(result)

d=session.evaluation.definitions

# I. Check for the time of building new definitions
%timeit d.get_definition(cache_random_names.pop())
# results1={"master":4.38,"slot":3.95} #us

# II. Accessing a builtin definition, having the scope
%timeit d.get_definition("System`Times")
# results2={"master": 115,"slot": 105 } #ns

# III.the same without the scope
%timeit d.get_definition("Times")
# results3={"master":115, "slot": 108 } #ns

# IV. Accessing a modified builtin definition, having the scope
%timeit d.get_definition("System`Plus")
# results2={"master": 108, "slot": 109} #ns

# V. the same without the scope
%timeit d.get_definition("Plus")
# results3={"master":111, "slot": 110 } #ns

test	master (ns)	slot (ns)	Improvement
I	4340	3950	9%
II	115	105	8%
III	115	108	8%
VI	108	109	-1%
V	111	110	0%

[rocky]

Please let's not go down this path right now. It is not the time for it. At some point we need to reassess how definitions and bindings on symbols work and then that is the time for that.

Too often we are digging down into low-level details while missing or not understanding the high-level problem and addressing that. We saw this with ordering the arrangement of tests in to_python() and blaming function calls being slow in Python when in fact the sloppy code was reevaluating , creating and converting data with abandon. We saw this also with the homegrown caching when what really is needed more was specialization of evaluation, initially by treating List in a special way, and detecting when we don't have to perform unnecessary evaluations possibly because we have a literal value or a generalization of that where we know that evaluation isn't going to change things.

The other thing that is bothersome is that we can't come up with a plan and stick to it. Right now the focus was supposed to be on boxing and formatting. There is a lot to do there that remains in this area.

So keep this in your back pocket for when the time is right. RIght now it is not the time.

In the short term there will be a 5.0.1 release of mathics to address the packaging issue. What is in master will go in too, so the Asymptote error in RectangeBox which was broken between 4.x and 5.0.0 will get fixed. I may add some more smallish doc urls.

[mmatera]

Please let's not go down this path right now. It is not the time for it. At some point we need to reassess how definitions and bindings on symbols work and then that is the time for that.

OK. In any case, this is not something with the aim to be merged, but just to record and share some experiments. During these experiments, I am finding small bugs / dead code that is what I am putting as PRs.

Once 5.0.1 be out, the idea is to continue with the plan of box refactoring.

[rocky]

Refactoring can go on right now in a branch. It just won't get merged until 5.0.1.