Mailman 3 March 2013 - Pandas-dev

Re: [Pandas-dev] Small question about vb_suite
by yoval p. March 27, 2013

March 27, 2013

----- Original Message ----- From: Stephen Lin Sent: 03/27/13 02:39 AM To: pandas-dev(a)python.org Subject: [Pandas-dev] Small question about vb_suite Hey guys, Just curious, Is there a convenient way to run just a particular set of benchmarks using one's locally checked out copy, right than going through the whole rigamorale of checking out two commits and comparing them? I'm modifying some tests to see if I can improve their stability, and I just want to check for syntax errors and such quickly... Stephen _______________________________________________ Pandas-dev mailing list Pandas-dev(a)python.org http://mail.python.org/mailman/listinfo/pandas-dev That would be vb_suite/perf_HEAD, which really should be part of test_perf. ...So now it is. ``` test_perf -H -r frame_.+ ``` Yoval

1 0

Small question about vb_suite
by Stephen Lin March 27, 2013

March 27, 2013

Hey guys, Just curious, Is there a convenient way to run just a particular set of benchmarks using one's locally checked out copy, right than going through the whole rigamorale of checking out two commits and comparing them? I'm modifying some tests to see if I can improve their stability, and I just want to check for syntax errors and such quickly... Stephen

2 1

Fast py2/py3 testing, fast vbench
by yoval p. March 26, 2013

March 26, 2013

I've made some improvement to the tooling we have for development, just making sure everyone is aware of what's available. - closed GH3099, caching cython build artifacts when running setup.py. - setup.py now checks for BUILD_CACHE_DIR envar so you can enable it without touch the source code - Once enabled, with a warm cache testing py26/27/32/33 takes only a couple of minutes compares with travis' ~15 on a quad core machine - if caching is enabled (for future commits, the envar is sufficiant) test_perf.sh will run much faster. - i've added an option to filter vbench by regex when running test_perf.sh. Quick iteration makes everything easier, I hope these changes do that. Here's an example of all of the above, comparing two adjacent commits on a reduced set of vbenches in 1min flat: λ export BUILD_CACHE_DIR="/tmp/.pandas_build_cache/" λ time ./test_perf.sh -b 18c7e6c -t 18c7e6c^ -r reindex ... Results: t_head t_baseline ratio name dataframe_reindex 0.3726 0.3726 1.0000 reindex_fillna_backfill_float32 0.0961 0.0961 1.0000 reindex_fillna_pad_float32 0.0959 0.0959 1.0000 frame_reindex_upcast 17.7334 17.7334 1.0000 reindex_daterange_backfill 0.1649 0.1649 1.0000 reindex_fillna_pad 0.1052 0.1052 1.0000 reindex_daterange_pad 0.1757 0.1757 1.0000 reindex_frame_level_align 1.0109 1.0109 1.0000 reindex_fillna_backfill 0.1035 0.1035 1.0000 reindex_frame_level_reindex 0.9586 0.9586 1.0000 frame_reindex_columns 0.3101 0.3101 1.0000 reindex_multiindex 1.1427 1.1427 1.0000 Columns: test_name | target_duration [ms] | baseline_duration [ms] | ratio - a Ratio of 1.30 means the target commit is 30% slower then the baseline. Target [18c7e6c] : BLD: check for BUILD_CACHE_DIR envar in setup.py Baseline [18c7e6c] : BLD: check for BUILD_CACHE_DIR envar in setup.py *** Results were also written to the logfile at '/home/user1/src/pandas/vb_suite.log' real 0m58.561s user 0m52.699s sys 0m1.645s

2 1

docs & builds
by Jeff Reback March 24, 2013

March 24, 2013

Wes/Chang not sure exactly how the doc builds happen, though I usually see updated by 5pm est, working? also windows dev builds stopped as of 3/14 thanks Jeff I can be reached on my cell 917-971-6387

4 3

I fought travis and won (sort of).
by yoval p. March 22, 2013

March 22, 2013

Hi guys, I've been frustrated with the turn-around time on travis, as it's become less a "CI" service then a "ATFMLI" (about 25 minutes later integration). Much of that build time is taken up by cythonizing and compilation even though the majority of PRs don't touch the cython code, and that's all wasted work. I hacked out a POC using network storage to cache build results bringing a complete run down to about ~8 minutes. Admittedly not amazing, but 2.5X-3X all the same. If any of you have an S3 API key you're willing to throw my way, I can set this up so anyone can opt in, via a magic incantation included in the commit message. Cheers, yoval

1 0

#3089 [PERF: regression from 0.10.1] discussion
by Stephen Lin March 20, 2013

March 20, 2013

As per the "we're getting too chatty on GitHub" comment, should we be moving extended issue discussion about bugs to this list whenever possible? I posted a few comments on #3089 just now but realized maybe starting an e-mail chain would be better.. Anyway, I'm looking into the issue, I suspect it's a corner case due to an array that's very large in one dimension but small in another, and possibly that there's compiler and architecture differences causing different results as well....Jeff, do you mind sending me your the output of "gcc -dumpmachine" and "gcc -dumpspecs" on the machine you ran vb_suite on? I'll set up a 64-bit dev machine going forward so I can test on both platforms. Thanks, Stephen

3 9

Managing the pandas firehose
by Wes McKinney March 20, 2013

March 20, 2013

Hi all, Welcome to the new pandas developer list! I thought it would be good to have a place for higher level discussions about the project and other initiatives, so I made this. One note that I wanted to pass on as we move toward the 0.11 release and going forward-- if I could get your help classifying and categorizing incoming issues, that would be a big help of staying on top of things. What does this mean? - Incoming issues: mark milestone as next release (bugs and other "must fixes" or low hanging fruit), next next release at your discretion. "Someday" otherwise. On GitHub you can see there are 30-something issues that have no milestone-- in January there were over 100 and I had a "milestone classification" binge. Would be great to not be the only one =P - Pull requests: also mark with a milestone please! This helps keep track of what release pull requests were a part of later on. - Label accordingly-- you all have been doing a good job with this. Code review and pull requests: - For one or two commits that aren't likely to be controversial (e.g. Jeff has been doing a lot of little doc additions), I don't mind if you push directly to master. If you think having someone else (doesn't need to be me necessarily) sign off would be good, then leave until that happens. - I don't mind if you use the green button-- I waffle between regular merges and cherry-picks when the number of commits is small. My main concern with ongoing development is making sure that things don't fall through the cracks and that bugs that come into the issue tracker get promptly classified. Any other thoughts? At some point we'll have to think about release management-- I have been carrying that torch since pandas 0.1, but at some point maybe someone else will do it. Part of it relies on having access to a fully-equipped Windows VM with 32 and 64 bit versions across all Python versions-- I have a virtualbox image that should get hosted someplace that is not a physical box in my apartment at some point. - Wes

3 3

Welcome
by Wes McKinney March 15, 2013

March 15, 2013

I just had this new mailing list created for high level discussions around pandas development. Hard to believe we've made it this long without one. I'll make an announcement about the development mailing list on PyData. Thanks, Wes

1 0