These are chat archives for dropbox/pyston

23rd
Apr 2015
Travis Hance
@tjhance
Apr 23 2015 00:57
is that part of the standard library? can we make our own implementation?
Chris Toshok
@toshok
Apr 23 2015 00:57
yeah
actually it looks like the BoxedWrapperObject’s are the cause of most of it :(
Travis Hance
@tjhance
Apr 23 2015 00:58
what’s a wrapper object?
Chris Toshok
@toshok
Apr 23 2015 00:58
slowpath_box_getattr.type(method-wrapper).__call__: 13747
used for wrapping the tp_ slots
out of the 24189 type.__call__’s, this is the breakdown of the things over 1000:
slowpath_box_getattr.type(capifunc).__call__: 1048
slowpath_box_getattr.type(type).__call__: 2590
slowpath_box_getattr.type(method).__call__: 6277
slowpath_box_getattr.type(method-wrapper).__call__: 13747
Michael Arntzenius
@rntz
Apr 23 2015 03:32
I found the bug that was causing differences between gcc 4.8 & 4.9
gcc was generating exception tables in a slightly different way that triggered a codepath that had a bug that hadn't been triggered before
in particular, exception tables map instruction ranges to lists of actions to take, and one "action" is "cleanup". but if you see a cleanup action, you shouldn't take it unless each other action fails to match; I was taking it immediately.
Travis Hance
@tjhance
Apr 23 2015 05:54
Hey guys, in cpython type_new there's this line type->tp_dictoffset = -(long)sizeof(PyObject *);
Does anybody know why dictoffset is able to be negative?
This would seem to indicate that the offset is not from the beginning of the object's data... but then, where is the offset from?
Travis Hance
@tjhance
Apr 23 2015 06:25
I checked the docs; it indicates offset from end (when it is negative)
Chris Toshok
@toshok
Apr 23 2015 21:10
wow, from the django spew:
created node for extends in 18.0ms
i figured it was something in the init that was taking a long time (there’s a dict((foo,bar) for foo,bar in blah) in there)
but: ExtendsNode.__init__ took 1.0ms
Travis Hance
@tjhance
Apr 23 2015 21:11
… does the GC run?
Chris Toshok
@toshok
Apr 23 2015 21:11
17ms of slowpath overhead? that seems extreme
Travis Hance
@tjhance
Apr 23 2015 21:11
(just throwing that out there)
Chris Toshok
@toshok
Apr 23 2015 21:12
i don’t have it gc’ing every request in this version of django, but i think if it did it would be on the order of 1000ms
Travis Hance
@tjhance
Apr 23 2015 21:12
hmm
Chris Toshok
@toshok
Apr 23 2015 21:13
hm, actually it looks like the tags don’t correspond to the classes themselves
so “extends” != ExtendsNode. “extends” -> do_extends(). that would explain things
yeah okay that explains it
interior nodes in the template hierarchy recursively invoke parser.parse()
yup: recursive parser.parse() took 17.0ms
Marius Wachtler
@undingen
Apr 23 2015 21:33
do you know what parser this is? is this djangos template parser?
Chris Toshok
@toshok
Apr 23 2015 21:35
yeah
Michael Arntzenius
@rntz
Apr 23 2015 22:32
I remember something with unreasonably high line counts coming up before (like >100,000)
and I'm getting a very high line count in this traceback
does anyone remember what the issue was?
Chris Toshok
@toshok
Apr 23 2015 22:32
from the pyston source_info?
Michael Arntzenius
@rntz
Apr 23 2015 22:32
yes
yes.
Chris Toshok
@toshok
Apr 23 2015 22:33
yeah in debug builds it’s or’ed with a large constant, iirc
in ast.cpp:
#ifdef DEBUG_LINE_NUMBERS                                                                                                                                                                                                                                                                                                                                                                                                                
int AST::next_lineno = 100000;
Kevin Modzelewski
@kmod
Apr 23 2015 22:37
it's because we're not setting the lineno on the relevant ast node
so it's still using the default one
you can put a breakpoint in the ast node creation to see which node it is
Chris Toshok
@toshok
Apr 23 2015 22:38
this django thing is definitely death by a million tiny cuts
lots of 0.2ms (cpython) vs 1.0ms (pyston)
Marius Wachtler
@undingen
Apr 23 2015 23:11
for 'testsite/manage.py migrate' cpython is currently beating us by 10x: 0.2sec vs 2sec...
Chris Toshok
@toshok
Apr 23 2015 23:13
looks like we’re failing to rewrite __iter__ calls. retry_in == 658 for the ic corresponding to this line: for match in matches:
the callee’s type and return value’s type should always be the same, but they’ll be different instances. do we guard on type or pointer value? /me looks
Chris Toshok
@toshok
Apr 23 2015 23:32
n
err
Michael Arntzenius
@rntz
Apr 23 2015 23:44
@kmod CMake is broken in a new and interesting way
Kevin Modzelewski
@kmod
Apr 23 2015 23:45
yeah? :)