Názory k článku
Optimalizace v Pythonu

Proč používat Psyco, které je zastaralé, v podstatě neudržované, nejede na x64 a je pomalejší než Pypy? Jinak použití iterátorů je v Pythonu 3 výrazně doporučeno, neboť se chovají líněji než ve verzi 3.

EDIT: samozřejmě se chovají líněji než ve verzi 2.

Príliš inteligentný redakčný systém vám nahradzuje úvodzovky za okrúhle aj v predformátovanom texte.

preklep: enumarete

Je příklad optimalizace u řetězce vůbec algoritmicky korektní? Mějme soubor s obsahem ": \n: \n: ", neoptimalizovaná funkce zavolaná s parametrem spaces=False vrátí řetězece "::::" a optimalizovaná funkce zavolaná se stejným parametrem vrátí ": :: :: ".

Redakční systém poškodil (přeformátoval) příspěvek. Jde o situaci, kdy v soubor obsahuje podřetězec schodný se separátorem.

Trochu mě zarazilo, že autor vůbec nedokumentoval k jakým úsporám jeho "optimalizacemi" dojde a protože jsem měl podezření, že jeho verze s "map" bude spíš pomalejší, schválně jsem si to zkusil.

Verze s map je oproti té předchozí (která slepuje stringy pomocí +, což je mimochodem v novějších verzích pythonu optimalizované pro takovéhle triviální případy a tedy dost rychlé) skoro dvakrát pomalejší (1.38 s vs 0.76 s pro můj test). Hlavní důvod je v tom, že autor porušil svoje vlastní pravidlo o používání vestavěných funkcí a použil vlastní (pythonovou) funkci v podobě lambda funkce. Tím přidal do kódu zbytečné volání funkce, které je v pythonu relativně drahé.
Ono je to totiž tak, že ty "kompilované" funkce se hodí nejvíce právě do těla cyklu, jedině tak vám může ten map něco ušetřit.

Přidávám svoje měření. Na mě to moc jako optimalizace nepůsobí.

Měřený kód:

def foo1(f, spaces=True):
    result = ''
    x = 0
    for line in f:
        result += str(x) + ':    ' + line
        x += 1
    if not spaces:
        result.replace(':    ', ':')
    return result

def foo2(f, spaces=True):
    result = ''
    x = 0
    separator = ":    " if spaces else ":"
    for line in f:
        result += str(x) + separator + line
        x += 1
    return result

def foo3(f, spaces=True):
    result = ''
    x = 0
    separator = ":    " if spaces else ":"
    for line in f:
        result += "%d%s%s" % (x, separator, line)
        x += 1
    return result

def foo4(f, spaces=True):
    separator = ":    " if spaces else ":"
    return "".join(map(
                    lambda param: "%d%s%s" % (param[0], separator, param[1]),
                    enumerate(f)
                ))

def foo5(f, spaces=True):
    separator = ":    " if spaces else ":"
    return "".join(("%d%s%s" % (line_no, separator, line) for line_no, line in enumerate(f)))


filename = "566KB_11442_rows.csv"

for x in range(40):
    with open(filename) as f:
        foo1(f)
    with open(filename) as f:
        foo2(f)
    with open(filename) as f:
        foo3(f)
    with open(filename) as f:
        foo4(f)
    with open(filename) as f:
        foo5(f)

Výsledky: (vybrány pouze časy foo?)

$ python -m cProfile -s cumulative rychlost.py
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       40    0.035    0.001    3.510    0.088 rychlost.py:31(foo4)
       40    0.001    0.000    3.272    0.082 rychlost.py:38(foo5)
       40    1.458    0.036    1.458    0.036 rychlost.py:22(foo3)
       40    1.006    0.025    1.006    0.025 rychlost.py:3(foo1)
       40    0.997    0.025    0.997    0.025 rychlost.py:13(foo2)

ncalls tottime percall cumtime percall filename:line­no(function)
37 63.378 1.713 161.906 4.376 <string>:20(foo3)
38 60.914 1.603 160.295 4.218 <string>:1(foo1)
37 60.939 1.647 158.263 4.277 <string>:11(foo2)
37 0.002 0.000 115.776 3.129 <string>:29(foo4)
37 0.002 0.000 114.006 3.081 <string>:36(foo5)

Ani jsem to nenechal doběhnout celé.
Athlon 800MHz

> Druhý prohřešek je, že se na neexistující klíč ptáme rovnou třikrát!

Tohle jsem nepochopil. Proč se ptáme na neexistující klíč třikrát a jak pomohla u neexistujících klíčů optimalizace?

Pokud jsem se správně díval, tak v opraveném kódu se ptá jen dvakrát.

co se tyce vykonu je navrh pythonu naprosto zoufaly. nejvic dokolen me dostala hlaska v dokumentaci o tom, ze operator "." je pomaly... a pokud je potreba ho pouzivat v cyklu, je lepsi si volanou metodu priradit do lokalni promenne.

To v pythone nemáte nič také ako StringBuilder?

co to s tim ma spolecneho?

Ale je. String ma metodu format().

pointa je v tom, ze operator tecka se v pythonu nepouziva ke scitani retezcu... takze stringbuilder i format nic neresi :-]]

Je tam snad StringIO, alias memory stream, aspoň se mi to tak při pohledu z rychlíku jeví. A je to asi jedna z nejefektivnějších metod jak v pythonu lepit stringy.

Navrh je mozna mistama zoufalej, ale je potreba srovnavat s konkurenci. Mame vadnouci Perl (6ka bude ready pro moje vnuky, bohuzel), stagnujici PHPcko () a nahypovany Ruby. Ve zmineny konkurenci je Python nejrychlejsi a podle me i nejperspektivnejsi (i kdyz rozstipnuti na 2 a 3 nebyla asi nej volba pod sluncem ... ukaze cas a optimalizace ;-))

Jo, slava LuaJit :-)

Zas raz biedne nastudovane tema. Nebudem davat ziadne cisla ale interpolacia retazcov je dost pomala. Ako najrychlejsie riesenie sa mi osvedcil ''.join(a,b,c)

Můj nejlepší pomocník pro dělání rychlých programů je můj starý počítač. (Athlon 800MHz s 768MB RAM) Po 12 letech ho stále používám jako svůj hlavní stroj.
Abych jen nečekal nma dončení, nemůžu si dovolit dělat pomalé programy.

Hlavní optimalizace je dobrá analýza problému, který se má řešit.
Znalost kritických míst programu.
Znalost možností, které daný jazyk nabízí, jeho slabin.

http://wiki.python.org/moin/PythonSpeed/PerformanceTips
http://wiki.python.org/moin/TimeComplexity
http://scipy.org/PerformancePython

Neuškodí znalost teorie grafů a výpočetní náročnosti.
http://en.wikipedia.org/wiki/Computational_complexity_theory
http://en.wikipedia.org/wiki/Analysis_of_algorithms

Když není zbytí, jde se o úroveň abstrakce níž.
http://www.root.cz/clanky/moduly-pro-python/
http://www.root.cz/clanky/moduly-pro-python-2/
http://www.root.cz/clanky/vytvarime-v-c-cpp-modul-pro-python/

A níž (ale tam jsem zatím jít nepotřeboval).
http://www.corepy.org/
http://www.grant-olson.net/python/pyasm

Poznamka, ze pro skutecnou rychlost je lepsi jit do C v clanku ponekud chybi. Stejne jako poznamka o algoritmizaci. Obecne, pokud chci neco opravdu rychle, asi si nevyberu Python.

Diky za odkaz na corepy, ne ze bych to zrovna potreboval, ale je to zajimave.

Chybi ti tam Cython po kterem ja saham jako po prvnim. Vlastne ne, kecam - nejdriv optimalizuji pouzitim Numpy, ale to bude tim ze vic pocitam, nez skladam stringy...

Máte pravdu, mohl jsem ho vypíchnout, i když na Cython je odkaz v diskuzi http://www.root.cz/clanky/vytvarime-v-c-cpp-modul-pro-python/nazory/

Tak tedy, http://cython.org/

V praxi vacsinou nebyva vykonnostny problem v nejakom generovani zoznamov alebo spajani stringov. Akademicky je to ok, prinos do praxe 0.

Přihazuji link na docela zajímavé povídání Guida o optimalizaci v Pythonu
http://www.py.cz/OptimalizacniHistorka

1. builtiny, bez lambd
2. nestaci-li 1. tak cython
3. nestaci-li 2. (kod pouziva ficury ktere cython dava interpreteru - treba slicovani nekterych typu) tak holt boost-python a c++ (rezie volani je celkem velka ale pointa je zachovat jednoduchost a 1:1 transparenci)

prasit c je az ta posledni moznost protoze cela koncepce pythonu je v tomto dost nestastna.

na nektere specialni ulohy lze pouzit ctypes (treba twisted server co spawnuje thready s sendfile())

pypy je slepa cesta protoze nikdy nemuze konkurovat prvotridnim hand-written JITum jako luajit2 (a sveho casu psyco).

a proto je pypy v mnoha pripadech i 30x rychlejsi nez CPython ....

proto umoznuje pretvorit python k obrazu svemu viz stackless python .... atd

Také bych se PyPy zastal.

Cite SvenHassel:

PyPy nabízí větší flexibilitu než běžné sémantiky jazyka Python, efektivnější využití paměti, sandboxing poskytuje micro-threads pro masivní paralelismus. PyPy 1.4 je ke stažení pro 32 bitové i 64 bitové systémy (GNU/ Linux, Microsoft Windows a Mac OS X).

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?java=on&fpascal=on&csharp=on&ghc=on&sbcl=on&v8=on&racket=on&hipe=on&vw=on&lua=on&jruby=on&python3=on&php=on&perl=on&yarv=on&calc=chart