stublifeless: 'An iterable of slices' seems rather overkill, and possibly self defeating. What is the advantage of this over just (min_index, max_index) ?08:56
lifelessstub: do you mean just special case the exact situation?09:01
stubDo we ever see more than one slice passed in?09:02
stubIf so, are the holes almost always a single comment?09:02
lifelessthe slices are09:02
lifeless[:40], [-40:]09:02
lifelessmore or less09:02
stubok. That makes sense then.09:03
stubIf the holes were small, we could be better off pulling them and skipping unwanted ones client side than the more complex WHERE clause.09:04
lifelessthe prototypical case is bug 109:04
_mup_Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubun09:04
lifelesswhere the hole is 1200 rows long09:04
lifelessstub: https://bugs.launchpad.net/launchpad/+bug/607935/comments/1209:05
_mup_Bug #607935: timeout on bugtask:+index <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/607935 >09:05
lifelessstub: doing two queries is 40ms total; one with the complex clause 30ms total09:06
stubset(row[1].ownerID for row in rows if row[1].ownerID)09:07
lifelessrather than the discard? its slower09:08
lifelessdoing a discard is one check for None, discarding in the loop is a check per row09:09
stubAny reason you want to keep eager_load_watches() in there?09:10
lifelessthinko, will delete.09:11
stublifeless: Hmm... if you do that, doesn't that mean build_comments_from_chunks() will be loading bugwatches one at a time from the DB?09:16
lifelesswe use that in one place only09:16
lifelessand that place is a bug context09:16
lifelessbugs have already preloaded all bug watches.09:16
lifelesseager_load_watches is already commented out to be uncalled09:17
stubRight. I've asked for a comment anyway - when I see code like that I assume database impedance mismatch issues and one-query-per-iteration performance because I don't know the call path.09:21
stubAnd tests for slicing behavior.09:21
lifelessfair enough09:27
lifelessthat method is /barely/ tested already; I'd like to nuke it entire for indexed_messages09:27
lifelessbut ETIME09:27
lifelessI'll add some tests tomorrow morning09:28
=== henninge_ is now known as henninge
=== wallyworld___ is now known as wallyworld

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!