- 14 Aug, 2015 6 commits
-
-
Kevin Modzelewski authored
We're keeping them around anyway
-
Kevin Modzelewski authored
Our exception throwing is still slower than CPython's, and it looks like it's partially due to the CAPI calls we do as part of the throwing process. For example, we have to actually create an exception object, which involves calling the exception type constructor, etc. We could try to jit this stuff, but for now add another fast-path to typeCall that should catch some of this. Also, add a fast-path that inlines most of the exception-creation behavior. Looks like this isn't too much faster than the above-mentioned fast-path.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Remove __attribute__((__malloc__)) from the gc
-
Kevin Modzelewski authored
support yield statements inside lambdas
-
Kevin Modzelewski authored
This attribute unfortunately lets the compiler skip stores if the pointer doesn't escape. This is bad because we will be looking at the memory during a collection; the compiler was skipping storing to cls and then the gc was crashing.
-
- 13 Aug, 2015 6 commits
-
-
Marius Wachtler authored
-
Marius Wachtler authored
-
Kevin Modzelewski authored
Have pypa parse strings directly
-
Kevin Modzelewski authored
Save the key hash in dictionaries
-
Kevin Modzelewski authored
Enable libpypa support for break/continue misuse detection
-
Kevin Modzelewski authored
Introduction of slice ast type & updated libpypa
-
- 12 Aug, 2015 15 commits
-
-
Kevin Modzelewski authored
This lets us avoid checking equality if the hash values didn't match. Checking equality can involve calling into user code, so it can be both a perf drain and a noticeable behavioral difference.
-
Kevin Modzelewski authored
Previously we would always write out the data to a file, and then call the parser on it. Most of this is refactoring to split the file-handling logic (ie reading from a FILE*) from stream-handling logic (encoding, counting line numbers, etc). One tricky point is handling encoding markers inside strings-to- parse; we (and CPython) handle the file case by creating a Python file object to iterate over it, and CPython handles the string case with a special function to pre-process and decode the string. This commit takes the approach of creating a cStringIO file-like-object and running it through the same decoding logic as the file case.
-
Kevin Modzelewski authored
Change isSubclass(obj->cls, int_cls) to PyInt_Check
-
Vinzenz Feenstra authored
-
Vinzenz Feenstra authored
-
Kevin Modzelewski authored
ie everything that the linter was warning about
-
Kevin Modzelewski authored
First job: check for cases where we call isSubclass() when it would be faster to call Py*_Check Probably overkill for this. Pretty cool though that it found a case that would have been impossible to spot textually, where there was an implicit this-> member access.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
More small optimizations
-
Kevin Modzelewski authored
Some work on the NumPy test
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Improve dictionary performance
-
Kevin Modzelewski authored
Get Pyston building on Fedora
-
- 11 Aug, 2015 13 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Previously it would have to call out to checkAndThrowCAPIException(), which is quite a bit slower than what it now can do, which is directly checking the return value.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Previously, we would just call these "conservative python" objects, and scan their memory conservatively. The problem with this is that the builtin type might have defined a custom GC handler that needs to be called in addition to the conservative scanning (ie it stores GC pointers out-of-band that are not discoverable via other gc pointers). We had dealt with these kinds of issues before which is why I added the "conservative python kind", but I think the real solution here is to say that to the GC, these objects are just python objects, and then let the type machinery decide how to scan the objects, including how to handle the inheritance rules. We were already putting "conservativeGCHandler" as the gc_handler on these conservative types, so let's use it.
-
Kevin Modzelewski authored
Refactors on types of GC objects
-
Kevin Modzelewski authored
-
Rudi Chen authored
-
Rudi Chen authored
Instead of GCKind::HIDDEN_CLASS, use GCKind::RUNTIME and require that the runtime objects have a gc_visit functions by inheriting from GCAllocatedRuntime.
-
Rudi Chen authored
-
Rudi Chen authored
-
Rudi Chen authored
Those should never exist because all Python objects should be created through the CPython API except for type objects. Unfortunately, some places like NumPy do that so we need a mean of patching it for now.
-