I think I found out why, for the QR test. First off, it's stable and not seed dependent (on my machine anyway, haven't looked too closely).
Trunk takes about 2 minutes and my new vector branch takes more than 3. >From what I've seen the problem is twofold: - norm1 is still slower in the new code - VectorViews suck at iterating through. They create a new DecoratorElement for every nonzero (so the index can be adjusted). The problem is that when picking the best algorithm, I made getIteratorAdvanceCost be the same as the vector being viewed not realizing the impact of creating new elements. I'll get back to you after I: - change norm1 to what it used to be - tweak the iterator advance cost for vector views On Fri, May 3, 2013 at 7:23 PM, Ted Dunning <[email protected]> wrote: > Shouldn't depend on seed. > > Very odd. > > Sent from my iPhone > > On May 3, 2013, at 8:24, Robin Anil <[email protected]> wrote: > > > QRDecompositionTest: I saw this from time to time. Sometimes it runs in > 0.2 > > seconds sometimes 100s. Seed related? > > > > > > > > On Fri, May 3, 2013 at 9:59 AM, Dan Filimon <[email protected] > >wrote: > > > >> QRDecompositionTest.fasterThanBefore() and most of the tests in > >> fpm.pfpgrowth take a really long time to run (FPGrowthSyntheticDataTest > >> took 98s on my machine). > >> > >> Could we do something about these? > >> Maybe move fasterThanBefore() into a benchmark and out of the tests > (like > >> VectorBenchmark) and simplify the fpm.* tests somehow? > >> > >> Thoughts? Thanks! > >> >
