Komentáře k článku

Optimalizace v Pythonu

Velmi často se stává, že rychlost výsledné aplikace je nepřímo úměrná rychlosti jejího vývoje – čím rychleji ji vyvineme, tím pomaleji běhá. Pak přichází vhodná chvíle na optimalizace. Pár milisekund ušetřených tu, pár tam, a na výsledku to je náhle znát. V článku si ukážeme, jak optimalizovat aplikace v Pythonu.

Zpět na článek

30 komentářů k článku Optimalizace v Pythonu:

  1. sputnikone

    Psyco

    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.

  2. pipoiuoupokj

    result += „%d%s%s“ % (x, separator, line)

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

  3. FB

    Chyba v kódu?

    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í „: :: :: „.

    1. FB

      Re: Chyba v kódu?

      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.

  4. beda

    zkoušel to autor vůbec spouštět?

    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.

    1. Krab

      Re: zkoušel to autor vůbec spouštět?

      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)
      1. Mintaka

        Re: zkoušel to autor vůbec spouštět?

        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

  5. David Grudl

    na neexistující klíč ptáme rovnou třikrát

    > 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?

    1. Tomáš

      Re: na neexistující klíč ptáme rovnou třikrát

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

  6. ded kenedy

    Re: Optimalizace v Pythonu

    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.

        1. ded kenedy

          Re: Optimalizace v Pythonu

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

      1. lyn_x

        Re: Optimalizace v Pythonu

        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.

    1. Jerry12

      Re: Optimalizace v Pythonu

      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 ;-))

  7. skrat

    Lepenie retazcov

    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)

  8. Mintaka

    Jak na to od lesa

    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

    1. JS

      Re: Jak na to od lesa

      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.

    2. andro

      Re: Jak na to od lesa

      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…

  9. Pavol

    Je to ako z velkej knihy zbytocnych syntetickych prikladov

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

  10. anonymous

    to je ale veda

    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).

    1. mimi

      Re: to je ale veda

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

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

    2. Mintaka

      Re: to je ale veda

      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).

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3464