From: Jeremy W. <jez...@ho...> - 2005-10-23 11:49:27
|
Hi, The typemap for T_HANDLE is as follows: if(SvROK($arg)) { if(hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0) != NULL) $var = ($type) SvIV(*(hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0))); else $var = NULL; } else $var = ($type) SvIV($arg); which becomes: if(SvROK(ST(0))) { if(hv_fetch((HV*)SvRV(ST(0)), "-handle", 7, 0) != NULL) handle = (HWND) SvIV(*(hv_fetch((HV*)SvRV(ST(0)), "-handle", 7, 0))); else handle = NULL; } else handle = (HWND) SvIV(ST(0)); in the code. If I am understanding this correctly we are doing 2 hash reads where we really only need to do one. As this typemap is used in nearly every method call we are doing lots of hash reads needlessly. Thoughts? Cheers, jez. |
From: Jeremy W. <jez...@ho...> - 2005-10-24 08:47:04
|
Just done some performance testing with this type map: if(SvROK($arg)) { SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0); if(out != NULL) $var = ($type) SvIV(*out); else $var = NULL; } else $var = ($type) SvIV($arg); Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap... NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @ 33666.63/s ( n=1000000) OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @ 26154.05/s ( n=1000000) Thoughts? Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-10-30 17:55:13
|
Jeremy White wrote: > Just done some performance testing with this type map: > > if(SvROK($arg)) { > SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0); > if(out != NULL) > $var = ($type) SvIV(*out); > else > $var = NULL; > } else > $var = ($type) SvIV($arg); > > Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap... > NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @ > 33666.63/s ( > n=1000000) > OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @ > 26154.05/s ( > n=1000000) > > Thoughts? I'm no typemap expert, but don't see anything wrong with that. Indeed, only doing the hv_fetch once seems like an obvious improvement. If you can hold onto the code until after the next release, then we can get it into CVS for the following release? Rob. |
From: Jeremy W. <jez...@ho...> - 2005-10-31 08:25:41
|
>Jeremy White wrote: >>Just done some performance testing with this type map: >> >> if(SvROK($arg)) { >> SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0); >> if(out != NULL) >> $var = ($type) SvIV(*out); >> else >> $var = NULL; >> } else >> $var = ($type) SvIV($arg); >> >>Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap... >>NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @ >>33666.63/s ( >>n=1000000) >>OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @ >>26154.05/s ( >>n=1000000) >> >>Thoughts? > >I'm no typemap expert, but don't see anything wrong with that. Indeed, >only doing the hv_fetch once seems like an obvious improvement. If you can >hold onto the code until after the next release, then we can get it into >CVS for the following release? No problem - there may be one issue. This code was compiled via Mingw, and as I'm declaring SV** out within a block of code, VC will complain. This may have been the reason that two hash reads were needed. I've a copy of VC now, so once the current build is out of the way, I'll do more testing. Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-10-31 19:04:28
|
Jeremy White wrote: >> Jeremy White wrote: >> >>> Just done some performance testing with this type map: >>> >>> if(SvROK($arg)) { >>> SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0); >>> if(out != NULL) >>> $var = ($type) SvIV(*out); >>> else >>> $var = NULL; >>> } else >>> $var = ($type) SvIV($arg); >>> >>> Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap... >>> NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @ >>> 33666.63/s ( >>> n=1000000) >>> OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @ >>> 26154.05/s ( >>> n=1000000) >> >> I'm no typemap expert, but don't see anything wrong with that. >> Indeed, only doing the hv_fetch once seems like an obvious >> improvement. If you can hold onto the code until after the next >> release, then we can get it into CVS for the following release? > > No problem - there may be one issue. This code was compiled via Mingw, > and as I'm declaring SV** out within a block of code, VC will complain. > This may have been the reason that two hash reads were needed. I've a > copy of VC now, so once the current build is out of the way, I'll do > more testing. I'm no C expert either, but I think it was always OK (C89 spec) to declare variables at the start of a block. (I think it was the C99 spec that allowed you to declare a variable anywhere). I think if it compiles with your somewhat old version of MinGW we'll be OK with VC98. We'll try it once the next release is out of the way. Regards, Rob. |