Menu
▾
▴
Re: [WWdevel] relative speed of sql_single and gdbm
|
From: Arnold P. <ap...@ma...> - 2005-03-17 16:29:53
|
At 10:47 AM 3/17/2005, John Jones wrote: >What about timing with old SQL.pm with binary removed? If you might have >a case conflict (database keys which differ only in case), then I wouldn't >try it until after the semester is over. It would tell us if there are >gains to be had by making further changes to SQL.pm. > >John >What about timing with old SQL.pm with binary removed? If you might have >a case conflict (database keys which differ only in case), then I wouldn't >try it until after the semester is over. It would tell us if there are >gains to be had by making further changes to SQL.pm. > >John With binary removed there seems to be a dramatic speed up. With your new version of SQL.pm [Thu Mar 17 11:16:24 2005] 38563 1111076184 - [/webwork2/mth162/7/6/] [runTime = 2.0 sec sql_single] [Thu Mar 17 11:16:28 2005] 38563 1111076188 - [/webwork2/mth162/7/6/] [runTime = 3.0 sec sql_single] [Thu Mar 17 11:16:31 2005] 38563 1111076191 - [/webwork2/mth162/7/6/] [runTime = 2.0 sec sql_single] [Thu Mar 17 11:16:35 2005] 38565 1111076195 - [/webwork2/mth162/7/6/] [runTime = 3.0 sec sql_single] [Thu Mar 17 11:16:38 2005] 38565 1111076198 - [/webwork2/mth162/7/6/] [runTime = 3.0 sec sql_single] [Thu Mar 17 11:16:41 2005] 38565 1111076201 - [/webwork2/mth162/7/6/] [runTime = 2.0 sec sql_single] [Thu Mar 17 11:17:05 2005] 38564 1111076225 - [/webwork2/mth162/8/8/] [runTime = 3.0 sec sql_single] With the old version of SQL.pm but with binary removed [Thu Mar 17 11:17:07 2005] 38564 1111076227 - [/webwork2/mth162/8/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:09 2005] 38564 1111076229 - [/webwork2/mth162/8/11/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:42 2005] 48562 1111076262 - [/webwork2/mth162/7/6/] [runTime = 1.0 sec sql_single] [Thu Mar 17 11:17:44 2005] 48564 1111076264 - [/webwork2/mth162/7/6/] [runTime = 1.0 sec sql_single] [Thu Mar 17 11:17:44 2005] 48562 1111076264 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:45 2005] 48562 1111076265 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:46 2005] 48564 1111076266 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:47 2005] 48564 1111076267 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:48 2005] 48562 1111076268 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:49 2005] 48575 1111076269 - [/webwork2/mth162/8/11/] [runTime = 1.0 sec sql_single] [Thu Mar 17 11:17:49 2005] 48564 1111076269 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] [Thu Mar 17 11:17:50 2005] 48564 1111076270 - [/webwork2/mth162/7/6/] [runTime = 1.0 sec sql_single] [Thu Mar 17 11:17:51 2005] 48562 1111076271 - [/webwork2/mth162/7/6/] [runTime = 0.0 sec sql_single] If using case insenstive keys does not mess up how things are read out (e.g. you want set "Exam1" to be in that form, not e.g. "EXAM1" or "exam1"), then it should be easy to enforce that there are no conflicts when userid's, set names, etc are created. Since I can not imagine that we have any database keys which differ only in case, I'll try this out now. Thanks. Arnie |
