- 23 Jul, 2015 26 commits
-
-
Kevin Modzelewski authored
Pow
-
Kevin Modzelewski authored
Gcc 4.9 gmp fix
-
Kevin Modzelewski authored
Improve __getattr__ handling
-
Kevin Modzelewski authored
Reduce number of optimization passes we run
-
Kevin Modzelewski authored
bjit: inline trivial helper functions
-
Kevin Modzelewski authored
Release leftover chunk in the TraceStack.
-
Chris Toshok authored
-
Chris Toshok authored
-
Rudi Chen authored
-
Marius Wachtler authored
-
Kevin Modzelewski authored
The previous set was based on trying to get the absolute best results on microbenchmarks; go back to the small set.
-
Kevin Modzelewski authored
Fix gc visiting code for running generators
-
Kevin Modzelewski authored
This is not quite the same as checking whether tp_getattro has been updated, since setting a __getattr__ will change tp_getattro. Usually this isn't that important since we will still need to do some special getattr handling, but in a couple specific cases we can optimize based on it. In particular, this commit optimizes calls to isinstance(inst, cls) on instances which have a __getattr__ set: in the common case (no __getattribute__, no custom __class__) we can know that the __getattr__ will not get called and we can stay on the isinstance fastpath.
-
Kevin Modzelewski authored
- rewriting a runtimeCall of an instancemethod was broken (this is a separate code path from the much-more-common callattr form). - we don't need to guard on the this->cls as often in Box::getattr, specifically in cases that are coming from typeLookup. Not because the classes are fixed (I think they can change), but because they are not allowed to change in a way that would change what Box::getattr has the guard for (guarding on attrs_offset and tp_dictoffset). - slightly change the place we guard on tp_getattro and tp_getattr to a place I think is a bit more correct (or at least easier to understand as being correct).
-
Kevin Modzelewski authored
ie the way that __getattr__ ends up getting called. Two main optimizations: - switch the initial attribute access (ie checking to see the attribute exists before calling __getattr__) to use a non-throwing api. For the typical case, even though the throwing would be a C API throw, the construction of the AttributeError is relatively expensive, and the object would be immediately discarded anyway. - add rewriting to the function They both roughly cut out half the overhead of accessing attributes on classes with __getattr__.
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Marius Wachtler authored
I verified with gdb that this now really visits all entries of the return context struct
-
Kevin Modzelewski authored
Improve isinstance speed
-
Kevin Modzelewski authored
Make sure to intern attribute string in PyObject_SetAttr.
-
Chris Toshok authored
Handle the extensive edge cases related to sequence slicing
-
- 22 Jul, 2015 14 commits
-
-
Kevin Modzelewski authored
bjit: omit frame pointer + use R12 for ASTInterpreter*
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
isinstance(obj, cls) needs to do a bunch of dynamic checking: it needs to check cls's class to see if it defines __instancecheck__, and it needs to fetch __class__ on obj. Most of those time those aren't overridden, so __instancecheck__ gets skipped and __class__ returns the type of the object. So use the same "type slot" machinery to cache whether an __instancecheck__ or custom __class__ attribute have gotten added. These are a bit different than the other slots since they are not "wrappers", they are simply bools that say whether or not the attribute exists. This makes the slot handling code a bit messier / more divergent from CPython, but I think it still makes sense to put this here since we get the hooking-on-attribute-updating and update-all-subclasses-as-well automatically.
-
Kevin Modzelewski authored
-
Rudi Chen authored
-
Marius Wachtler authored
This reduces the number of stack access, because previously when we accessed a field of the interpreter we always had to load it first from stack into a reg - and now we have a dedicated reg. This is currently only a very small perf change but when #736 lands this becomes more important.
-
Kevin Modzelewski authored
My theory is that specifying the separate cache directories interacts badly with travis-ci. I think it will either delete any cache directories that look like they are no longer cached (ie when it finishes the debug build it will delete the release ccache dir since it looks unused), or maybe it keeps them around but only checks the most recent build for a cache hit (ie the debug build might check and only find ccache_release). So anyway, try always specifying both directories. Another option is to do the simpler thing and use a single directory for both caches, but I want to only change one thing at a time.
-
Kevin Modzelewski authored
Slightly speedup ASTInterpreter::initArguments
-
Chris Toshok authored
Call finalizers during garbage collection with ordering
-
Rudi Chen authored
-
Rudi Chen authored
- Non-integer and non-None object passed into slices can fall back to item operator. - Support indexeable items for slices when appropriate. - Increase setitem and delitem ic slot sizes so that the rewriter can succeed. - Increase the performance of using slice operators on built-in types avoiding a lot of the guards and slowpath.
-
Rudi Chen authored
- Call either the item functions (e.g. __getitem__) or slicing function (e.g. __getslice__) to match the CPython behavior. - Implement __getslice, __setslice__, __delslice__, for lists. - Implement __setslice__ for strings. - Some refactoring of common functionality for indexing and slicing. - A lot of tests.
-
Rudi Chen authored
Make sure CPython functions like PyObject_Del do not free any objects. It's better to let the GC free all objects because only the GC can guarantee that there are no more references to an object.
-
Rudi Chen authored
New testing helper function ensures that objects are garbage collected and their finalizers tested in a more strict order. This reduces the chances that an object isn't collected because a reference remains in the stack, but it's hard to fully solve this problem as long as we have conservative stack scanning.
-