PyQuery přidává jQuery syntaxi bez měřitelné režie v tomto benchmarku

PyQuery staví nad lxml API ve stylu jQuery. Napříč pěti velikostmi stránek od 1 KB do 10 MB byly všechny zobrazené mediány nižší než u čistého lxml, včetně rozdílu 1,5 % u největší velikosti. Benchmark ale neprokazuje, že je tento wrapper rychlejší; nenašel rozdíl dost velký na to, aby změnil rozhodnutí u tohoto scénáře „vyber a přečti“.

Od 10 KB výše byl ve zobrazených mediánech také v rámci několika procent od selectolax. Bez předem stanovené hranice ekvivalence je to spíš těsný výsledek než statistická remíza.

Co je PyQuery

PyQuery je Python knihovna, která vám nad stromem dokumentu lxml dává selector-chain API podobné jQuery. Testovaná verze: 2.1.0, licence BSD, 2 380 hvězdiček na GitHubu, 59 otevřených issues, poslední push 2026-07-27.

Oficiální reference: PyQuery documentation.

from pyquery import PyQuery as pq
d = pq(html)
titles = [e.text_content() for e in d("h3.title")]
hrefs = [e.get("href") for e in d("a")]

Elementy, které vrací, jsou elementy lxml, takže vše, co umíte s lxml, funguje dál. To je celý záměr: PyQuery je vrstva pro pohodlnější práci, ne parser. pip install pyquery přidá 3 balíčky — lxml, cssselect a samotné PyQuery — a zabere 20,1 MiB, přičemž skoro vše tvoří kompilované rozšíření lxml.

Pokud jste v Node používali cheerio, v Pythonu je to stejná myšlenka API. Dva selektory testované zde fungovaly v obou; test ale neprokazuje úplnou shodu selector jazyka mezi cssselect a cheerio.

Jak probíhalo měření

Tento základ výzkumu už měl parser benchmark s vlastností, kterou většina benchmarků postrádá: paritní bránu, která hashuje extrahovaný obsah — seřazené title a seřazené hrefy — proti referenčnímu parseru, takže knihovna, která si práci zjednoduší, nemůže projít s falešně rychlým časem. Pět velikostí stránek, 50 iterací, tři nezávislé běhy.

Přidání PyQuery do testu vyžadovalo dvě věci.

Opětovné spuštění reference. selectolax běžel znovu ve stejném procesu. Jeho content hash seděl na 5 z 5 velikostí a jeho p50 byl mezi 0,989× a 1,079× oproti publikované hodnotě — jde tedy o stejný stroj i stejné testovací prostředí.

Spuštění lxml ve stejném procesu také. Publikovaný benchmark uvádí stroj a verzi Pythonu, ale ne verze knihoven, takže jeho řádek s lxml mohl pocházet z jiné verze lxml, než na kterou se zde PyQuery vrství. Porovnání přes takovou mezeru by ve skutečnosti porovnávalo dvě verze lxml a vydávalo to za daň wrapperu. Spuštění lxml vedle PyQuery odstraňuje nejasnost — v tomto venv jsou oba na lxml 6.1.1.

p50 v milisekundách, medián ze tří běhů, vše v jednom procesu. parser-bench.json. Všechny tři content hashe odpovídaly referenci na každé velikosti.

Režie wrapperu, která se neukázala

PyQuery vyšel na úrovni nebo lépe než čisté lxml ve všech zobrazených mediánech. To ale není důkaz, že wrapper dělá parsing rychlejším. Tři mediány z běhu a žádná předem daná hranice ekvivalence podporují užší závěr: na tomto testovacím materiálu se neobjevila režie selectorů, která by měnila rozhodování.

Na 10 MB byly tři běhy PyQuery 162.86, 163.17 a 161.13 ms; u lxml 169.46, 165.25 a 164.18. Rozsahy jsou blízko, ale nepřekrývají se. Na 1 MB se mediány liší o 0,5 %. Tyto malé rozdíly podporují praktický závěr, ne tvrzení o statistické ekvivalenci.

Mechanismus je dost přímočarý: pq(html) jednou vytvoří strom lxml, d("h3.title") přeloží CSS selektor přes cssselect stejně jako tree.cssselect(), a elementy, které se vrací, jsou elementy lxml. V tomto měřeném hot path tak PyQuery dělá jen minimum práce. Traversal, manipulace, opakované dotazy, import a paměť jsou mimo tvrzení o čase pro selektor.

Těsné výsledky od 10 KB výše

Užitečnější závěr je první sloupec.

Od 10 KB výše byl rozptyl mezi nejrychlejším a nejpomalejším mediánem u selectolax, lxml a PyQuery 4,5 % na 10 KB, 5,4 % na 100 KB, 0,5 % na 1 MB a 4,5 % na 10 MB. Tento běh nebyl testem ekvivalence; praktický závěr je, že takové rozdíly by u tohoto workloadu většinou nerozhodly o volbě parseru.

selectolax je na 1 KB skutečně rychlejší — 0.0286 ms proti 0.0456 a 0.0508 — ale tento řádek je nepoužitelný. Napříč třemi parsery je rozptyl v této velikosti 77,6 % a vlastní tři běhy selectolax se pohybovaly mezi 0.0267 a 0.0404 ms. Při 28 mikrosekundách dominuje časovač i plánovač procesů. Tam bych nic nehodnotil.

Pro tento scénář „vyber selektor a načti data“ vybírejte mezi těmito třemi podle API a podle měřených závislostí, ne podle domnělé hierarchie rychlosti. PyQuery neprokázalo rozhodovací penalizaci proti lxml. Selectolax používá jiný parser stack, ale tento článek neměřil jeho instalační stopu, pokrytí wheelů ani požadavky na build stejným způsobem.

Pro srovnání: publikovaný benchmark postavil na stejném 10 MB fixture ještě dvě další Python možnosti, a právě ty se skutečně liší:

Publikované hodnoty z bench_parse.json.

Historické řádky benchmarku ukazují BeautifulSoup více než o řád výš než rychlejší mediány parserů na tomto fixture. Tyto řádky nebyly přeměřeny s aktuální dvojicí PyQuery/lxml ve stejném procesu, takže jsou spíš kontext než řízený násobek pro hlavní verdikt.

Uložený řádek pro cheerio byl 2 927.89 ms (2927.8857 v parser-bench.json) a content hashe seděly. Tento výsledek napříč runtime závisí také na Node, verzích balíčků a historických běhových podmínkách; nelze ho číst jako izolovaný násobek rychlosti jedné knihovny.

Reálné náklady na nasazení

Oficiální reference: PyQuery on PyPI.

metadata-snapshot.json.

Tři balíčky jsou čistá závislostní stopa a dva z nich — lxml a cssselect — už stejně používá mnoho Python projektů na scraping. V takovém případě je marginální cena PyQuery jen několik desítek kilobajtů.

20,1 MiB tvoří kompilovaná rozšíření lxml, ne PyQuery. Je to stejných zhruba 20 MiB, které zaplatíte i při přímém používání lxml.

Balíček má licenci BSD. V datovaném snapshotu měl 59 otevřených issues a poslední push tři týdny před testem; samotné tyto údaje ale neprokazují kvalitu údržby ani budoucí kompatibilitu.

Paměť a co s ní udělá rozbitý HTML

Dvě věci, které každá recenze v této sérii označila jako netestované, jsou nyní změřené.

Širší kontext zátěžového testu je v porovnání paměti a špatně utvořeného HTML pro deset knihoven.

Vrchol resident memory, přes /usr/bin/time -l, vždy jeden čerstvý proces na buňku — import floor je cena za načtení a nečinný běh knihovny, peak už zahrnuje dokument.

memory-results.json. Základy pro Python a Node nejsou mezi sebou přímo srovnatelné; interpreter je v obou případech uvnitř.

PyQuery je lehčí než resiliparse na velkém dokumentu — 172.5 MiB proti 225.1 — i přes vyšší import floor. Strom lxml je úsporný a většina 30,3 MiB import floor u PyQuery je prostě načtené lxml, ne něco, co dělá PyQuery navíc.

Rozbité HTML. Dvanáct dokumentů, z nichž každý rozbíjí přesně jednu věc — neukončené tagy, špatně zanořené inline elementy, atributy bez uvozovek s mezerami, osamělé uzavírací tagy, vůbec žádné <html>, duplicitní atributy, dokument uříznutý uprostřed tagu, špatné entity, neukončený <script>, lživé deklarace charsetu, komentář obsahující markup a 600 úrovní zanoření — plus dva dobře utvořené kontrolní dokumenty v odpovídajících velikostech, protože „nic nevrátil“ vypovídá o špatném HTML jen tehdy, když knihovna na čistém dokumentu stejné velikosti také mlčí.

pyquery vyhodilo chybu na 0 z 14 a v 1 případě nevrátilo nic, přičemž obnovilo 10/22 sentinelů napříč rozbitými fixture (malformed-results.json). Jeden fixture je z tohoto počtu vyřazen: podle HTML5 je všechno po neukončeném <script> skutečně script content, takže ztratit to tam je správně a naopak ho zachránit by bylo odchylkou. Bez přímých alternativ vedle něj je 10/22 spíš pozorování robustnosti než pořadí parserů.

Klady a zápory

Ve prospěch. Syntaxe jQuery, známá každému, kdo psal front-end JavaScript nebo používal cheerio. V tomto testu se proti čistému lxml neobjevila rozhodovací režie selectorů. Jen 3 balíčky a 2 z nich už nejspíš ve stromu máte. Vrací elementy lxml, takže můžete dál používat nástroje lxml. BSD. Content hashe seděly referenci na všech pěti velikostech.

Proti. 20,1 MiB, kvůli lxml. 2 380 hvězdiček znamená mnohem menší komunitu než 30 449 u cheerio — tedy méně hotových příkladů, když se něco chová divně. Je to jen pohodlná vrstva, takže co neumí lxml, to neumí ani ona. A pokud jste doufali, že jQuery API přinese výkon, nepřinese: přináší ergonomii a skutečnou práci dělá parser pod tím.

Kdo by měl PyQuery použít a kdo ne

Použijte PyQuery, pokud vy nebo váš tým preferujete v Pythonu jQuery styl selektorů. Měřená cesta konstrukce, dvou selekcí a čtení dat neukázala proti lxml žádnou rozhodovací penalizaci; jiné operace PyQuery se neměřily.

Použijte přímo lxml, pokud vám víc vyhovuje XPath nebo chcete o jeden balíček méně. Tohle měření neukázalo žádný důvod v rychlosti selectorů, proč mezi nimi volit.

Zvažte selectolax, pokud jeho parser API a závislostní stack sedí vašemu projektu. Řádek pro 1 KB je výslovně bez pořadí a tento článek nepodporuje tvrzení o „nejmenší závislosti“.

V Node je analogickou volbou cheerio. Uložené cross-runtime řádky tu byly pomalejší, ale rozdíly mezi runtime a historickým během neumožňují čistý závěr pouze o knihovně.

Kam patří spravované API

PyQuery parsuje HTML, které už máte. Nestahuje stránky, nespouští JavaScript ani neřeší anti-bot vrstvy — žádný parser v tomto srovnání to nedělá a na mnoha reálných cílech je to právě ta těžší část.

Poznámka autora: Thunderbit je naše spravovaná varianta pro načítání/renderování URL a extrakci. Tady nebyla proti PyQuery benchmarkovaná. Hranice je jednoduchá: máte už HTML a chcete lokální selektory, nebo chcete získávání stránky a extrakci jako službu.

Upřímné shrnutí: pokud máte HTML a znáte své selektory, PyQuery je bezplatné a příjemné. Pokud se selektory pořád lámou nebo stahujete ve velkém, je to už úplně jiný nákup.

Pro širší pohled náš přehled web scraping API pokrývá hostované možnosti a pillar open-source scraperů ty self-hosted. Pokud se z parsovaného výstupu krmí model, převod HTML do Markdownu v Pythonu je místo, kde se nejvíc ztrácí věrnost.

Vyzkoušet Thunderbit pro extrakci webových dat

Má smysl PyQuery používat?

Ano, pokud chcete v Pythonu syntaxi ve stylu jQuery a vámi měřená cesta výběru a čtení odpovídá vašemu workloadu.

Benchmark nenašel žádnou rozhodovací režii selectorů proti lxml při zachování parity content hashů. Neprokázal ale nulovou cenu celé knihovny.

Napříč pěti velikostmi zůstaly mediány tří Python parserů dost blízko, takže pro tento úkol bude pravděpodobně důležitější shoda s API než drobné rozdíly v rychlosti. Než z toho uděláte širší pořadí parserů, nastavte hranici ekvivalence a spusťte znovu přesně ty alternativy.

Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free

Časté dotazy

Zpomaluje PyQuery lxml? V tomto běhu se neobjevila žádná rozhodovací režie selectorů. Napříč pěti velikostmi stránek jeho mediány skončily na úrovni nebo pod čistým lxml, přičemž obě knihovny běžely ve stejném procesu a na lxml 6.1.1. Na 10 MB se rozsahy nepřekrývaly: PyQuery 161.13–163.17 ms a lxml 164.18–169.46 ms. pq(html) vytváří strom lxml a testované selektory se kompilují přes cssselect.

Je selectolax rychlejší než PyQuery? Jeho medián na 1 KB byl nižší, ale tento řádek je bez pořadí, protože na mikrosekundové škále dominuje variance. Od 10 KB výše byly rozdíly mediánů 0,5 %–5,4 %. To je pro tento workload blízko, ne důkaz ekvivalence nebo překrývajících se rozsahů ve všech případech.

Proč znovu spouštět lxml místo citace publikovaného čísla? Protože publikovaný benchmark uvádí stroj a verzi Pythonu, ale ne verze knihoven. Jeho řádek s lxml mohl pocházet z jiné lxml než té, kterou dnes obaluje PyQuery, a takový rozdíl verzí by vypadal jako daň wrapperu, která ve skutečnosti neexistuje. Spuštění obou v jednom procesu na lxml 6.1.1 odstraňuje nejednoznačnost.

Jak si vede proti cheerio? Stejná obecná myšlenka API, jiné prostředí. Dva selektory testované zde fungovaly v obou a content hashe seděly na všech pěti velikostech; to ale neprokazuje úplnou kompatibilitu selectorů. Uložené časy cheerio byly pomalejší, ale rozdíly mezi runtime a historickým runem neumožňují tvrdit násobek pouze na úrovni knihovny.

Co se tu netestovalo? Paměť byla měřena jako peak RSS pro samotný import, pro dokument 226 KB a pro dokument 10 MB. Rozbité HTML bylo testováno na 12 poškozených dokumentech plus dvou kontrolách. Stále netestované zůstávají výkon manipulace a traversal v PyQuery, cache opakovaných dotazů, fetchování URL, konkurence a realistické workloady z reálných webů. Čas pro 1 KB zůstává bez pořadí.