PyQuery, Bu Benchmark’te Kararları Etkileyecek Bir Seçici Ek Yükü Olmadan jQuery Sözdizimi Sunuyor

PyQuery, lxml üzerine jQuery tarzı bir API ekler. 1 KB ile 10 MB arasındaki beş farklı sayfa boyutunda ölçülen medyanların hepsi, ham lxml’den daha düşüktü; en büyük boyutta fark %1,5 idi. Ama bu benchmark, sarmalayıcının daha hızlı olduğunu kanıtlamıyor; yalnızca bu seçim ve okuma kararını değiştirecek kadar büyük bir fark göstermedi.

Ayrıca 10 KB’dan itibaren gösterilen medyanlarda selectolax ile de birkaç puan içinde kaldı. Önceden tanımlanmış bir eşdeğerlik eşiği olmadan bu, istatistiksel bir beraberlik değil, yakın bir sonuçtur.

PyQuery nedir?

PyQuery, lxml belge ağacı üzerinde jQuery’nin seçici ve zincirleme API’sini sunan bir Python kütüphanesidir. Test edilen sürüm: 2.1.0, BSD lisanslı, 2.380 GitHub yıldızı, 59 açık sorun, son push 2026-07-27.

Resmî dokümantasyon: 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")]

Döndürdüğü öğeler lxml öğeleridir; yani lxml ile yapabildiğiniz her şey burada da geçerlidir. Tasarımın özü de bu: PyQuery bir ayrıştırıcı değil, kullanım kolaylığı katmanıdır. pip install pyquery, 3 paket getirir — lxml, cssselect ve PyQuery’nin kendisi — ve 20,1 MiB yer kaplar; bunun neredeyse tamamı lxml’in derlenmiş eklentileridir.

Node tarafında cheerio kullandıysanız, Python’daki genel API fikri aynıdır. Burada denenmiş iki seçici her iki tarafta da çalıştı; test, cssselect ile cheerio arasında seçici dili açısından tam bir eşleşme olduğunu kanıtlamıyor.

Ölçüm nasıl yapıldı?

Bu araştırma tabanında zaten bir parser karşılaştırma düzeneği vardı ve çoğu benchmark’ta olmayan bir özelliğe sahipti: çıkarılan içeriği hash’leyen bir eşitlik kapısı — sıralanmış başlıklar ve sıralanmış href’ler — referans parser’a karşı kontrol ediliyor; böylece bir kütüphane bazı işleri atlayarak sahte bir hız kazancı gösteremiyor. Beş sayfa boyutu, 50 tekrar, üç bağımsız çalıştırma.

PyQuery’yi buna eklemek iki şey gerektirdi.

Referansı yeniden çalıştırmak. selectolax aynı işlem içinde bir kez daha çalıştırıldı. İçerik hash’i 5 boyutun 5’inde de aynı çıktı ve p50 değeri yayımlanan sonuçların 0,989× ile 1,079× arasında kaldı — yani aynı makine ve aynı test ortamı kullanıldı.

lxml’i de aynı işlem içinde çalıştırmak. Yayımlanan benchmark makineyi ve Python sürümünü kaydediyor, ancak kütüphane sürümlerini kaydetmiyor; bu yüzden oradaki lxml satırı, PyQuery’nin burada sardığı lxml sürümünden farklı bir sürüme ait olabilir. O boşluk üzerinden kıyas yapmak, iki farklı lxml sürümünü karşılaştırıp bunu sarmalayıcı maliyeti gibi göstermek olurdu. lxml’i aynı süreçte çalıştırmak bu soruyu ortadan kaldırır — bu sanal ortamda ikisi de lxml 6.1.1.

p50 milisaniye, üç çalıştırmanın medyanı, hepsi tek bir işlem içinde. parser-bench.json. Tüm boyutlarda üç içerik hash’i de referansla eşleşti.

Olmayan sarmalayıcı maliyeti

PyQuery, gösterilen her medyanda ham lxml kadar ya da ondan daha iyi sonuç verdi. Bu, bir sarmalayıcının ayrıştırmayı daha hızlı hale getirdiğinin kanıtı değil. Üç çalıştırmanın medyanları ve önceden tanımlanmış bir eşdeğerlik eşiğinin olmaması, daha dar bir sonuca işaret ediyor: bu testte kararları etkileyecek bir seçici ek yükü görülmedi.

10 MB’da PyQuery’nin üç çalıştırması 162.86, 163.17 ve 161.13 ms idi; lxml’in üç çalıştırması ise 169.46, 165.25 ve 164.18 ms idi. Aralıklar birbirine yakın ama çakışmıyor. 1 MB’da iki medyan arasındaki fark %0,5. Bu küçük çalıştırmalar istatistiksel eşdeğerlik değil, pratik bir değerlendirme sağlar.

Mekanizma yeterince basit: pq(html) bir kez lxml ağacı oluşturur, d("h3.title") seçicisini cssselect üzerinden tree.cssselect() gibi derler ve geri dönen öğeler lxml öğeleridir. Ölçülen sıcak yolda PyQuery’ye ait çok az iş vardır. Dolaşım, değiştirme, tekrarlı sorgular, import ve bellek kullanımı bu seçici süresi iddiasının dışındadır.

10 KB’dan itibaren yakın sonuçlar

Daha faydalı bulgu ilk sütundur.

10 KB’dan itibaren selectolax, lxml ve PyQuery arasında en hızlı ile en yavaş medyan arasındaki fark 10 KB’da %4,5, 100 KB’da %5,4, 1 MB’da %0,5 ve 10 MB’da %4,5 idi. Bu çalışma bir eşdeğerlik testi değildi; pratik yorum, bu farkların çoğu parser seçimini bu iş yükünde değiştirmeyeceği yönündedir.

selectolax, 1 KB’da gerçekten daha hızlıdır — 0.0456 ve 0.0508’e karşı 0.0286 ms — ama o satır kullanılabilir değil. Bu boyutta üç parser arasındaki fark %77,6 ve selectolax’ın kendi üç çalıştırması 0.0267 ile 0.0404 ms arasında değişti. 28 mikrosaniyede zamanlayıcı ve işletim sistemi zamanlayıcısı baskın hale gelir. Orada hiçbir şeyi sıralamam.

Bu seçici ve okuma iş yükü için, bu üç seçenek arasında performans hiyerarşisi varsayarak değil, API ve ölçülen bağımlılık gerçeklerine bakarak seçim yapın. PyQuery, lxml’e karşı karar değiştirici bir ceza göstermedi. Selectolax farklı bir parser yığını kullanır; ancak bu yazı onun kurulu boyutunu, wheel kapsamasını ya da derleme gereksinimlerini aynı temelde ölçmedi.

Karşılaştırma için, yayımlanan benchmark aynı 10 MB örneğinde iki Python seçeneğini daha gösterdi; asıl fark yaratanlar onlar:

Yayımlanan değerler bench_parse.json dosyasındandır.

Geçmiş benchmark satırları, bu örnekte BeautifulSoup’un daha hızlı parser medyanlarının bir hayli üzerinde olduğunu gösteriyor. Bu satırlar mevcut süreçteki PyQuery/lxml çiftiyle yeniden çalıştırılmadı; dolayısıyla bunlar ana hüküm için kontrollü bir çarpan değil, bağlam bilgisidir.

Cheerio’nun kayıtlı satırı, eşleşen çıkarılmış içerik hash’leriyle birlikte 2.927,89 ms idi (2927.8857 içinde parser-bench.json). Bu farklı çalışma zamanı sonucu Node’a, paket sürümlerine ve tarihsel çalıştırma kontrollerine de bağlıdır; tek başına bir kütüphane hız çarpanı olarak okunmamalıdır.

Kurulum gerçeği

Resmî kaynak: PyQuery on PyPI.

metadata-snapshot.json.

3 paket oldukça temiz bir bağımlılık yapısıdır ve bunların ikisi — lxml ile cssselect — pek çok Python scraping projesinde zaten bulunur. Bu durumda PyQuery’nin ek maliyeti yalnızca birkaç on kilobayttır.

20,1 MiB, PyQuery’nin değil lxml’in derlenmiş eklentileridir. lxml’i doğrudan kullanmak için de ödeyeceğiniz yaklaşık 20 MiB aynıdır.

Paket BSD lisanslıdır. Tarihli anlık görüntüde 59 açık sorun vardı ve testten üç hafta önce bir push yapılmıştı; bu gözlemler tek başına bakım kalitesini ya da gelecekteki uyumluluğu kanıtlamaz.

Bellek ve bozuk HTML’nin etkisi

Bu serideki her incelemenin henüz test edilmemiş olarak bıraktığı iki konu artık ölçüldü.

Daha geniş stres testi bağlamı için on kütüphanelik bellek ve bozuk HTML karşılaştırmasına bakın.

Zirve çalışan bellek, /usr/bin/time -l ile, her hücre için yeni bir süreçte ölçüldü — import tabanı, kütüphanenin yüklenmiş ve boşta maliyetini gösterir; zirveler dokümanı da içerir.

memory-results.json. Python ve Node başlangıç değerleri birbirleriyle doğrudan karşılaştırılamaz; yorumlayıcı ikisinin de içindedir.

PyQuery, büyük dokümanda resiliparse’tan daha hafif çıktı — 225.1’e karşı 172.5 MiB — buna rağmen import tabanı daha yüksektir. lxml’nin ağaç yapısı kompakttır ve PyQuery’nin 30,3 MiB’lik tabanının çoğu PyQuery’den değil, lxml’in yüklenmesinden gelir.

Bozuk HTML. Her biri tam olarak bir şeyi bozan on iki belge — kapatılmamış etiketler, yanlış iç içe geçmiş satır içi öğeler, içinde boşluk olan tırnaksız öznitelikler, fazla kapanış etiketleri, hiç <html> olmaması, yinelenen öznitelikler, etiket ortasında kesilmiş belge, hatalı entity’ler, kapatılmamış bir <script>, yanıltıcı bir charset bildirimi, işaretleme içeren yorum ve 600 seviyeli iç içe geçme — artı aynı boyutlarda iki düzgün kontrol belgesi, çünkü "hiçbir şey döndürmedi" ifadesi, kütüphane aynı boyuttaki temiz bir belgede de sessizse bozukluk hakkında bir şey söylemez.

pyquery, 14 belgenin 0’ında hata verdi ve 1 belgede hiçbir şey döndürmedi; bozuk örneklerdeki işaretçilerin 10/22’sini kurtardı (malformed-results.json). Bir örnek bu sayımdan çıkarıldı: HTML5’e göre kapatılmamış bir <script> sonrasındaki her şey script içeriğidir; bu yüzden orada kaybetmesi doğrudur, geri kazanması ise sapmadır. Yanındaki doğrudan alternatiflerin işaretçi sonuçları olmadan 10/22, parser sıralaması değil, dayanıklılık gözlemidir.

Artılar ve eksiler

Artıları. Front-end JavaScript yazmış ya da cheerio kullanmış herkese tanıdık gelecek jQuery sözdizimi. Bu testte ham lxml’e karşı karar değiştirici bir seçici ek yükü görülmedi. Sadece 3 paket ve bunların 2’si muhtemelen zaten projenizde var. lxml öğeleri döndürdüğü için lxml teknikleri kullanılabilir. BSD. İçerik hash’leri beş boyutun tamamında referansla eşleşti.

Eksileri. lxml nedeniyle 20,1 MiB. 2.380 yıldız, cheerio’nun 30.449 yıldızına göre çok daha küçük bir topluluk demek — bir şey tuhaf olduğunda daha az örnek ve çözüm. Bu bir kolaylık katmanıdır; lxml’nin yapamadığını o da yapamaz. Ve jQuery API’sinin size performans kazandıracağını umuyorsanız, kazandırmaz: kazandırdığı şey kullanım kolaylığıdır, işi yapan ise alttaki parser’dır.

Kim kullanmalı, kim kullanmamalı?

PyQuery kullanın eğer siz ya da ekibiniz Python’da jQuery tarzı seçicileri tercih ediyorsanız. Ölçülen oluşturma, iki seçim ve okuma yolu lxml’e karşı karar değiştirecek bir ceza göstermedi; PyQuery’nin diğer işlemleri zamanlanmadı.

Doğrudan lxml kullanın eğer XPath’i tercih ediyorsanız ya da bir paket daha az olsun istiyorsanız. Bu çalışma, ikisi arasında seçim yapmayı gerektiren bir hız nedeni göstermedi.

selectolax’ı değerlendirin eğer parser API’si ve bağımlılık yapısı projenize uyuyorsa. 1 KB satırı açıkça sıralanmamıştır ve bu makale “en küçük bağımlılık” iddiasını desteklemiyor.

Node tarafında, cheerio benzer API yapısını sunar. Burada kayıtlı çapraz çalışma zamanı satırları daha yavaştı, ancak çalışma zamanı ve tarihsel çalıştırma farklılıkları, yalnızca kütüphane bazlı temiz bir sonuç çıkarmayı engeller.

Yönetilen API nereye oturur?

PyQuery, zaten elinizde bulunan HTML’i ayrıştırır. HTML çekmez, JavaScript render etmez, anti-bot katmanıyla uğraşmaz — bu karşılaştırmadaki hiçbir parser bunu yapmaz ve gerçek hedeflerin çoğunda işin zor kısmı da zaten budur.

Yazar notu: Thunderbit bizim URL girip çekme/render etme ve çıkarma için sunduğumuz yönetilen seçenektir. Burada PyQuery ile karşılaştırılmadı. Asıl ayrım şudur: HTML zaten sizde mi ve yerel seçiciler mi istiyorsunuz, yoksa sayfa alma ve çıkarma bir servis olarak mı yürütülsün istiyorsunuz?

Dürüst çerçeve şu: HTML sizdeyse ve seçicilerinizi biliyorsanız, PyQuery ücretsiz ve rahattır. Seçiciler sürekli kırılıyorsa ya da büyük ölçekte veri çekiyorsanız, bu başka bir satın alımdır.

Daha geniş alan için, web scraping API derlememiz barındırılan seçenekleri; açık kaynak scraper rehberimiz ise kendi barındırdıklarınızı kapsıyor. Ayrıştırılmış çıktı bir modele gidecekse, Python’da HTML’yi Markdown’a dönüştürme bölümünde doğruluk nerede kayboluyor görebilirsiniz.

Web Verisi Çıkarmak için Thunderbit’i Deneyin

PyQuery kullanmalı mısınız?

Evet, Python’da jQuery tarzı sözdizimi istiyorsanız ve ölçülen seçici/okuma yolu sizin iş yükünüzü temsil ediyorsa.

Benchmark, içerik hash uyumunu korurken lxml’ye karşı karar değiştirici bir seçici ek yükü bulmadı. Ancak kütüphanenin bütünü için sıfır maliyet olduğunu da kanıtlamadı.

Beş boyut boyunca üç Python parser medyanı o kadar yakındı ki, bu işte API uyumu muhtemelen hızdan daha önemli olacaktır. Bu yargıyı daha geniş bir parser sıralamasına çevirmeden önce, bir eşdeğerlik eşiği tanımlayın ve tam alternatifleri yeniden çalıştırın.

Web Verisi Çıkarmak için Thunderbit’i Deneyin Get Started Free

SSS

PyQuery, lxml’i yavaşlatır mı? Bu çalışmada karar değiştirici bir seçici ek yükü görülmedi. Beş sayfa boyutunun tamamında medyanlar ham lxml’deki değerlerin altında ya da onlara eşitti; her ikisi de aynı işlem içinde lxml 6.1.1 kullanılarak çalıştı. 10 MB’da yakın aralıklar çakışmadı: PyQuery 161.13–163.17 ms, lxml 164.18–169.46 ms. pq(html) bir lxml ağacı oluşturur ve test edilen seçiciler cssselect üzerinden derlenir.

selectolax, PyQuery’den daha mı hızlı? 1 KB medyanı daha düşüktü, ancak mikro-saniye ölçeğinde değişkenlik baskın olduğu için o satır sıralanmadı. 10 KB’dan itibaren medyan farkları %0,5–%5,4 arasındaydı. Bu iş yükü için bu yakın bir sonuçtur; her durumda eşdeğerlik ya da çakışan aralıklar kanıtı değildir.

Neden yayımlanan sayıyı alıntılamak yerine lxml’i yeniden çalıştırdınız? Çünkü yayımlanan benchmark makineyi ve Python sürümünü kaydediyor ama kütüphane sürümlerini kaydetmiyor. Oradaki lxml satırı, PyQuery’nin bugün sardığından farklı bir lxml’den gelmiş olabilir; sürüm farkı, aslında olmayan bir sarmalayıcı maliyeti gibi görünürdü. İkisini aynı işlem içinde lxml 6.1.1 ile çalıştırmak bu belirsizliği kaldırır.

Cheerio ile karşılaştırması nasıl? Aynı genel API fikri, farklı ekosistem. Burada denenen iki seçici her ikisinde de çalıştı ve beş boyutun tamamında içerik hash’leri eşleşti; bu, tam seçici uyumluluğu kanıtlamaz. Cheerio’nun kayıtlı süreleri daha yavaştı, ancak çapraz çalışma zamanı ve tarihsel çalıştırma kontrolleri yalnızca kütüphane bazlı bir çarpan iddiasını engeller.

Burada ne test edilmedi? Bellek, yalnızca import, 226 KB’lık belge ve 10 MB’lık belge için pik RSS olarak ölçüldü. Bozuk HTML, 12 bozuk belge ve iki eşleştirilmiş kontrol ile test edildi. Hâlâ test edilmemiş olanlar: PyQuery’nin dönüştürme ve dolaşım performansı, tekrarlı sorgu önbellekleme, URL çekme, eşzamanlılık ve gerçek sitelerde temsilî iş yükleri. 1 KB zamanlaması hâlâ sıralanmamıştır.