A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-March/043007.html below:

[Python-Dev] Who cares about the performance of these opcodes?

[Python-Dev] Who cares about the performance of these opcodes?Michael Hudson mwh at python.net
Wed Mar 10 06:03:56 EST 2004
Greg Ewing <greg at cosc.canterbury.ac.nz> writes:

> "Phillip J. Eby" <pje at telecommunity.com>:
>
>> If the goal is to remove lines from the switch statement, just move the 
>> code of lesser-used opcodes into a C function.  There's no need to 
>> eliminate the opcodes themselves.
>
> Naively, one might think that, if the code is rarely used, even if
> it's inside the switch, it'll rarely be in the cache and thus wouldn't
> make much difference.

I'm not sure that's so much the issue.  It would be bad if (say) the
top of the switch and the LOAD_FAST opcode were in i-cache conflict,
and it's probably crap like this that accounts for the random-seeming
performance fluctuations as you tinker with eval_frame.

> But I suspect the cacheing issues are more subtle than just the total
> amount of code in the switch statement, and the only way to be sure
> is to measure.

on multiple architectures with multiple compilers, etc, etc.

Chees,
mwh

-- 
  You can lead an idiot to knowledge but you cannot make him 
  think.  You can, however, rectally insert the information, 
  printed on stone tablets, using a sharpened poker.        -- Nicolai
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4