sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

further speed up tests

help edit space_dashboard

Ticket

further speed up tests+status
closed
help edit space_dashboard
further speed up tests+priority
low
help edit space_dashboard
further speed up tests+tag
Tests
help edit space_dashboard
further speed up tests+commit
 

 

further speed up tests+solution

help edit space_dashboard

Some of the biggest opportunities remaining are:

  1. getting rid of unnecessary time in defaults setting in Card.new.  We could do that by adding :skip_defaults to a gazillion test calls (though surely some of them need the defaults).  I'm guessing much of this will go away when we refactor permissions
  2. further optimizing card#save.  Most of the biggest gains there have been exploited, but I was using a fairly simple case -- there may be other opportunities for optimizing when saving plus cards, cards with many references, etc.
  3. selectively preloading the cache for some specs, but not all.  For the ones where it's unnecessary it slows things down, so it ends up being a wash.  But if we're able to pick and choose, I think we could do some good.
  4. spot optimize slowest tests

 

 

help edit space_dashboard

So here's the question for the group: do we still want to consider #1 and #2 from speed up tests+solutions? [1. fixture import (aka test db reset) only on request instead of every run  (should save 1-3s? every run), and 2. review all tests for card setup that can be moved to the global fixture set]  I'm not clear on whether those are still consistent with our approach.


I think my new take is that I'd rather spend the time building the new permissions system and then optimizing the tests to work with that. --Ethan

What tools do we have for measuring performance? Both for tests and for more production like loads.

  --Gerry Gleason.....Thu Jan 06 10:47:46 -0800 2011

not enough. we use new relic, but have only the lowest level of support. I might be willing to invest in more. Lew has a benchmarking spreadsheet somewhere, though I think the old data may not be super useful, as I think it's based on running stuff on his old laptop.

  --Ethan McCutchen.....Thu Jan 06 11:41:08 -0800 2011

fwiw, I lowered this to "low" pri because I think testing performance is more or less under control now, but production performance needs to be a high priority for us. (which I think you were already implying)

  --Ethan McCutchen.....Thu Jan 06 11:42:27 -0800 2011

Yes, exactly. I think it is well under control for testing and that focusing on test performance could have you doing things that are bad for production performance.

When I get the current branch more under control, I may want to try to generate new data and compare to Lew's data for trends and just to be sure nothing has gotten too far out from what it was.

So if you have any useful links on this, please share. Should we have another ticket for production performance, maybe?

  --Gerry Gleason.....Thu Jan 06 13:12:11 -0800 2011

Thanks John, for all the Wagn housecleaning. I think we need a word for that. Not quite Wagneering, but keeping the wagn rolling along smoothly.

  --Gerry Gleason.....Sun Jan 23 04:11:41 -0800 2011

Yer welcome. Some of the work is refactoring (e.g. synthesizing, moving content to more appropriate pages). That use of "refactoring" goes back to Ward's wiki, although some wonder if it's only a metaphor :-). The later terms WikiGnome or WikiGardener for someone who tends a wiki suggests "gardening" as a more general verb term.

  --John Abbe.....Sun Jan 23 05:12:48 -0800 2011

don't think there's anything helpful here.

  --Ethan McCutchen.....2013-03-26 21:25:46 +0000