Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!feeder2.ecngs.de!ecngs!feeder.ecngs.de!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <8Y_3x.668959$LI3.568865@fx24.am4>
References: <554f2bb6$0$13011$c3e8da3$5496439d@news.astraweb.com> <fNP3x.641427$3i4.583649@fx29.am4> <555028d8$0$12997$c3e8da3$5496439d@news.astraweb.com> <8Y_3x.668959$LI3.568865@fx24.am4>
Date: Mon, 11 May 2015 09:12:10 -0500
Subject: Re: Calling a function is faster than not calling it?
From: Skip Montanaro <skip.montanaro@gmail.com>
To: BartC <bc@freeuk.com>
Cc: Python <python-list@python.org>
Content-Type: multipart/alternative; boundary=089e013cbeacbd794d0515cef638
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.365.1431353538.12865.python-list@python.org>
Lines: 50
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90382

--089e013cbeacbd794d0515cef638
Content-Type: text/plain; charset=UTF-8

On Mon, May 11, 2015 at 4:50 AM, BartC <bc@freeuk.com> wrote:

> You just seem surprised that using eval() to do this is slower than a
> direct call.


Well, it is surprising. Most uses of eval() are to evaluate Python
expressions in string form. That I expect to be quite slow, given the
parsing+byte compilation overhead. I wouldn't expect eval()ing a code
object to be all that different than calling the function containing the
code object.

My guess (without looking in ceval.c) is that the code path through the VM
has been tweaked heavily over the years to try and speed it up. Except for
places where that path overlaps with the path for eval(code_object), I
doubt any attention has been paid to speeding up eval. I could certainly be
way off-base here. Perhaps the path taken through the interpreter for
eval(code_object) is more-or-less a subset of the path taken for a simple
function call.

Skip

--089e013cbeacbd794d0515cef638
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, May 11, 2015 at 4:50 AM, BartC <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:bc@freeuk.com" target=3D"_blank">bc@freeuk.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">You just seem surprised that using eval() t=
o do this is slower than a direct call.</blockquote></div><br>Well, it is s=
urprising. Most uses of eval() are to evaluate Python expressions in string=
 form. That I expect to be quite slow, given the parsing+byte compilation o=
verhead. I wouldn&#39;t expect eval()ing a code object to be all that diffe=
rent than calling the function containing the code object.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">My guess (without loo=
king in ceval.c) is that the code path through the VM has been tweaked heav=
ily over the years to try and speed it up. Except for places where that pat=
h overlaps with the path for eval(code_object), I doubt any attention has b=
een paid to speeding up eval. I could certainly be way off-base here. Perha=
ps the path taken through the interpreter for eval(code_object) is more-or-=
less a subset of the path taken for a simple function call.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Skip</div><div class=
=3D"gmail_extra"><br></div></div>

--089e013cbeacbd794d0515cef638--