Equivalent of Perl chomp?

[Bengt Richter]

On 4 Feb 2002 08:15:11 GMT, bokr at oz.net (Bengt Richter) wrote:
[... a bunch of timing discussion and code ...]

>[23:00] C:\pywk\crdtsc>python endsvslice.py 1 10 850 1000
>10 loops, 1000 avgloops, 850 tadj
> endswith1:  1312, avg  1327
> endswith2:  1335, avg  1366
> endswith3:  1368, avg  1407
> endswith4:  1432, avg  1388
>    slice1:   669, avg   740
>    slice2:  1898, avg  1942
>    slice3:  1937, avg  1934
>    slice4:  1915, avg  1907
>
>IOW, endswith did not take a huge jump measuring my way, but
>the slice was certainly affected from 1 to 2.
>
>The little dip for slice4 is curious. Here are some more trials of that:
>    slice4:  1898, avg  1916
>    slice4:  1909, avg  1913
>    slice4:  1909, avg  1913
>Hm, maybe slice3 above is off?
>    slice3:  1945, avg  1934
>    slice3:  1926, avg  1933
>    slice3:  1928, avg  1942
>    slice3:  1927, avg  1941
>Curiouser and curiouser... anyway, no huge anomalies ;-)
>
I am wondering if the dip might be due to being able to access
aligned chunks better than odd sized ones. Testing that theory:

Strings where len(gtail)%2 == 0 seem to be a little faster. I
pasted in a second run for consistency check. I was looking
for some advantage in %4 but I don't see it here. Is the actual
string data aligned on 4 or 2 bytes in python's strings?

The routine being timed is

def slice_n(s):
    global gnslice, gtail
    return s[-gnslice:] == gtail

If the leftmost printout number below is trial, each trial sets up
    gnslice = trial+1
    gtail = ' '*trial+'\n'
before calling the timing stuff. Note constant 2850 offset
to make number differences stand out more.
Time units are 300mhz ticks.

[13:56] C:\pywk\crdtsc>python endsvslice9.py 9 10 2850 1000 20
10 loops, 1000 avgloops, 2850 tadj 20 ntrials
  0:    slice_n: -1056, avg -1044    |  -1043
  1:    slice_n:   152, avg   164    |    159 <- (maybe not gaining via loop yet?)
  2:    slice_n:   102, avg   124    |    123 
  3:    slice_n:   109, avg   102    |    104 <-
  4:    slice_n:    66, avg   124    |    126 
  5:    slice_n:    96, avg   101    |     99 <-
  6:    slice_n:   101, avg   132    |    123 
  7:    slice_n:    74, avg   106    |    103 <-
  8:    slice_n:   103, avg   127    |    130 
  9:    slice_n:    97, avg   107    |    107 <-
 10:    slice_n:   103, avg   128    |    125 
 11:    slice_n:   126, avg   108    |    109 <-
 12:    slice_n:   134, avg   125    |    124 
 13:    slice_n:    88, avg   108    |    100 <-
 14:    slice_n:   109, avg   128    |    124 
 15:    slice_n:    79, avg   109    |    106 <-
 16:    slice_n:   135, avg   153    |    140 
 17:    slice_n:    78, avg   113    |    115 <-
 18:    slice_n:   116, avg   154    |    148 
 19:    slice_n:   125, avg   123    |    119 <-

Kind of interesting what you can pick up. I wonder what
a spectral analysis of raw timing result sequences would
reveal. I'd expect to pick up any cyclic behavior in
memory pool usage, etc.

Regards,
Bengt Richter