I get these results (best timing):
  try-variant: 10.24s
  regex: 9.58s
So on my laptop try:except: function loses about 5% to regex - probably it 
depends on hardware/OS.
Still there is a serious reason why to stick with regexp. try: int(x) is not 
really checking for an int - it checks for a _number_. So floats will pass 
that test.
And as Massimo pointed out - we don't really check for an int - we check for 
valid id. Function should be remamed, yes.

Also there is another problem with your testing - you get too much noise this 
way. 5-10 ms _per_loop_ is too slow. I get about 9.993 seconds for 40M (!) 
operations effectively - 0.25usec per loop - about 10k times faster than 
yours. You can check it yourself, my script is attached.

On Tuesday 09 June 2009 23:43:05 AchipA wrote:
> Regardless of speed, if you *really* want to check for integers,
> you'll need a far more complex regex (how do you handle sign ? int
> size ?). int() does all that for you without too much effort.
>
> But, for the record, to satisfy my own curiosity, too - one quickie
> profiling coming up (python 2.5.2, x86_64 linux):
>
> blinky:~# python -m timeit "s=[str(i) for i in range(10000)]"
> 100 loops, best of 3: 4.64 msec per loop
> blinky:~# python -m timeit "s=[str(i) for i in range(10000)]" "def
> is_integer(i):" "  try:" "    int(i)" "    return True"  "  except:
> return False" "for i in s:"  "  is_integer(i)"
> 100 loops, best of 3: 9.32 msec per loop
> blinky:~# python -m timeit "s=[str(i) for i in range(10000)]" "import
> re" "integer_pat=re.compile('[0-9]+$')" "is_integer=integer_pat.match"
> "for i in s:"  "  is_integer(i)"
> 100 loops, best of 3: 10.5 msec per loop
>
> So, technically it's 4.68 vs 5.86msec which is a ~20% speed increase
> over the simplified regex even with the user function overhead. defs
> might be slow, but regexes are no rockets either (C or not).
>
> On Jun 9, 8:05 pm, Iceberg <iceb...@21cn.com> wrote:
> > I don't know but you'd better do some profiling if you really want to
> > find out. IMHO, try...except might be fast, but wrapping it inside a
> > user-defined function could be another story, because defining a
> > function is expensive in python, so we shall call native function
> > (implemented by C) whenever possible.
> >
> > On Jun10, 0:48am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > good point. Anyway, the function is no longer called as often as
> > > Alexey originally pointed out, so it would make a negligible
> > > difference. I will change it though.
> > >
> > > Massimo
> > >
> > > On Jun 9, 11:24 am, AchipA <attila.cs...@gmail.com> wrote:
> > > > Any particular reason not doing is_integer via a 'try: int(i) except:
> > > > return False'  statement ? It should be faster than regexes.
> > > >
> > > > On Jun 7, 1:49 pm, Iceberg <iceb...@21cn.com> wrote:
> > > > > On Jun7, 6:35pm, Alexey Nezhdanov <snak...@gmail.com> wrote:
> > > > > > > 2) is_integer is a fast call, but with 1.1k (!) calls ...
> > > > > >
> > > > > > Replaced it with my own version:
> > > > > > integer_pat=re.compile('[0-9]+$')
> > > > > > is_integer=lambda x: integer_pat.match(x)
> > > > > > it's about 2.3 times faster. C version would be even better.
> > > > >
> > > > > If so, perhaps this is even better:
> > > > >
> > > > >   integer_pat=re.compile('[0-9]+$')
> > > > >   is_integer=integer_pat.match
> > > > >
> > > > > Because lambda is considered as much slower than built-in
> > > > > functions, AFAIK.
>
> 


-- 
Sincerely yours
Alexey Nezhdanov

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Attachment: a.py
Description: application/python

Attachment: b.py
Description: application/python

Attachment: sh
Description: application/shellscript

Reply via email to