These are chat archives for dropbox/pyston

15th
Apr 2015
Marius Wachtler
@undingen
Apr 15 2015 00:00
Then the issue is that pypa got compiled without fp.
Kevin Modzelewski
@kmod
Apr 15 2015 00:06
ah ok
ok I think I'll try out this hack with libunwind first
and then it shouldn't be too bad to switch it to the fp-based unwinding later once we have that
Chris Toshok
@toshok
Apr 15 2015 03:22
weird, my django-fixes branch is now much, much slower
Chris Toshok
@toshok
Apr 15 2015 14:10
like, 1000x slower :/
Marius Wachtler
@undingen
Apr 15 2015 15:47
:-(
do you think the slowdown is caused by a patch on HEAD or is it a new change to your local django fixes branch?
Chris Toshok
@toshok
Apr 15 2015 15:51
pretty sure it’s something in the last few commits, but i git reset’ed the branch back to the tip of master and the performance was still bad, so going to bisect in a bit :)
there are three places where I made changes that will cause additional allocations, I think: changing zip to take varargs instead of 2, changing list() to take varargs to fix the list subclass problem in django’s ResultList class, and getting rid of the __iter__ on str_cls (which will force string iteration to use the sequence iterator, which iterates until an exception is thrown)
but none of those seem like they would be that painful.. the list change would likely be the worst
the /admin/ page doesn’t depend on any of those changes, though, so it should be easy enough to bisect.
Michael Arntzenius
@rntz
Apr 15 2015 18:39
hm, apparently there is a libdw-dwarf-unwind library that does DWARF-based unwinding slightly faster than libunwind: http://lwn.net/Articles/579508/
Michael Arntzenius
@rntz
Apr 15 2015 20:19
hm, make perf_dbg_a seems to hang our Makefile
Kevin Modzelewski
@kmod
Apr 15 2015 20:21
hmm it works for me but is super slow
interestingly it's true for perf_release_a as well
but perf_a, which just calls perf_release_a, is fast
oh hmm these definitely seem slower to me than they used to
I think it's because of adding test/cpython/ to the search path
not sure why that would have such a big effect
Michael Arntzenius
@rntz
Apr 15 2015 20:25
there are a lot of files in the cpython dir
mine hangs for 30s, at which point I give up
after removing the cpython dir from make_search, it still hangs for 30s
so something is definitely terribly wrong, on my machine at least
this is 30s without even running any other command (make -n)
make perf_release_a finishes immediately
adding cpython makes make perf_release_a take 0.5s instead of 0.1s.
maybe that's what you're seeing
but for me, make perf_dbg_a just hangs
Michael Arntzenius
@rntz
Apr 15 2015 20:30
@kmod can we try to chase down these build issues together, and also get CMake working for me?
Kevin Modzelewski
@kmod
Apr 15 2015 20:35
oh weird, removing the cpython directory from make_search made it faster from ~6.5s to ~0.5s
Michael Arntzenius
@rntz
Apr 15 2015 20:35
hm.
Kevin Modzelewski
@kmod
Apr 15 2015 20:36
I'll come over in a sec
Michael Arntzenius
@rntz
Apr 15 2015 20:36
what's your make --version?
Kevin Modzelewski
@kmod
Apr 15 2015 20:36
3.81
Michael Arntzenius
@rntz
Apr 15 2015 20:37
hm, I'm on 4.0
Kevin Modzelewski
@kmod
Apr 15 2015 20:40
our make_search handling causes us to look for things like test/tests/test/cpython/a.py :P
Michael Arntzenius
@rntz
Apr 15 2015 20:42
oh, screwy
it recurses
that's probably the problem
Michael Arntzenius
@rntz
Apr 15 2015 20:58
@kmod Ok, given that we're going to be switching to CMake, should I spend time trying to fix this or not?
Kevin Modzelewski
@kmod
Apr 15 2015 20:59
well I think this is part of the stuff that will stay
Daniel Agar
@dagar
Apr 15 2015 21:50
perf_* is in cmake, but doesn't quite work right with ninja
Chris Toshok
@toshok
Apr 15 2015 21:52
huh, it’s the strDecode/strEncode fix. commit before that fix? 980ms for /admin/. commit after that fix? 5900ms
a 10x increase in the number of StopIteration exceptions being thrown
Marius Wachtler
@undingen
Apr 15 2015 21:59
:-(
Michael Arntzenius
@rntz
Apr 15 2015 22:04
now I'm getting yet another CMake error I don't understand :/
the llvm-trunk CMakefile seems to be complaining about "In-source builds are not allowed"
Daniel Agar
@dagar
Apr 15 2015 22:05
do it from another directory
I do CC=clang CXX=clang++ cmake -GNinja -DTEST_THREADS=4 ~/git/pyston
Michael Arntzenius
@rntz
Apr 15 2015 22:07
I'm doing make USE_CMAKE=1 pyston_dbg from the pyston dir, which is supposed to do all the directory-changing magic
but even doing CC=clang CXX=clang++ cmake -GNinja ~/pyston from inside of a fresh ~/pyston-build-dbg dir produces this error
Marius Wachtler
@undingen
Apr 15 2015 22:11
is ~/pyston your source directory or an empty one (build dir)?
oh ignore that: I got the arguments swapped...
Chris Toshok
@toshok
Apr 15 2015 22:24
that said, 980ms before that change is also pretty terrible (and not what it used to be)