| 00:19.01 | *** join/#storm jamesh (~james@canonical/launchpad/jamesh) |
| 00:48.53 | *** join/#storm jkakar (~jkakar@127.Red-83-60-96.dynamicIP.rima-tde.net) |
| 01:24.32 | *** join/#storm m4v (~znc@unaffiliated/m4v) |
| 01:29.19 | *** join/#storm EdwinGrubbs (~quassel@108-80-210-6.lightspeed.hstntx.sbcglobal.net) |
| 01:29.19 | *** join/#storm EdwinGrubbs (~quassel@canonical/launchpad/edwingrubbs) |
| 03:50.02 | *** join/#storm fcorrea (~fcorrea@201-62-110-81-ma.static.vivax.com.br) |
| 05:39.30 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 06:22.28 | *** join/#storm danilos (~danilo@cable-178-148-38-107.dynamic.sbb.rs) |
| 06:22.28 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 06:46.55 | *** join/#storm wallyworld (~quassel@27-33-46-253.static.tpgi.com.au) |
| 07:44.18 | *** join/#storm esteve (~quassel@cli-5b7ee22f.bcn.adamo.es) |
| 08:18.17 | *** join/#storm bigjools (~quassel@82-71-93-254.dsl.in-addr.zen.co.uk) |
| 08:18.17 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 08:57.51 | *** join/#storm bigjools (~quassel@82-71-93-254.dsl.in-addr.zen.co.uk) |
| 08:57.51 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 10:32.18 | *** join/#storm wgrant (~wgrant@ubuntu/member/wgrant) |
| 11:08.56 | *** join/#storm thumper (~thumper@125-236-193-95.adsl.xtra.co.nz) |
| 11:08.56 | *** join/#storm thumper (~thumper@canonical/launchpad/thumper) |
| 11:46.41 | *** join/#storm fcorrea (~fcorrea@201-62-110-81-ma.static.vivax.com.br) |
| 12:04.34 | *** join/#storm artista_frustrad (~artista_f@187.54.58.224) |
| 12:24.00 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 13:12.12 | *** join/#storm fcorrea (~fcorrea@187.3.22.136) |
| 13:57.18 | *** join/#storm zmijunkie (~sascha@business-188-111-082-104.static.arcor-ip.net) |
| 15:22.32 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 16:11.47 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 16:53.24 | mgedmin | instantiating Storm objects is surprisingly expensive |
| 17:00.38 | mgedmin | is there a way to see what SQL is going to be executed when I have a ResultSet() object? |
| 17:01.00 | mgedmin | (without installing a debug tracer and executing the query itself) |
| 17:05.48 | mgedmin | anyway, about the expense: |
| 17:06.27 | mgedmin | same SQL costs 433 ms to get ORM objects, but just 175 ms to get column values (if I enumerate all column values) |
| 17:06.38 | mgedmin | (there are 1979 rows) |
| 18:11.36 | *** join/#storm sidnei (~sidnei@200-203-4-97.cslce701.dsl.brasiltelecom.net.br) |
| 18:24.17 | mgedmin | why does StoreDataManager.commit() need 120 ms to figure out that none of the 2668 objects I've loaded have been modified during this transaction? |
| 18:24.59 | mgedmin | or, rather, I guess my question should be: is that normal/expected, or am I doing stupid things? |
| 19:00.52 | *** part/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 19:57.21 | jkakar | mgedmin: Some of the expense is just Python allocating stuff... |
| 19:57.39 | jkakar | mgedmin: Some of it is all the event machinery being hooked up, the stuff that tracks when properties change... |
| 19:58.05 | jkakar | mgedmin: Some of it is that when you call ResultSet.values your basically not using Storm at all, it's just a very thin wrapper around the DB-API at that point. |
| 19:58.28 | jkakar | mgedmin: As far as whether 120ms for 2668 object is normal, I don't know... we'd have to profile it to see what's going on. |