[python] Re: igui2

[Zdenek Pavlas]

Ludek Smid wrote:

> A proc tedy existuje Anygui [http://anygui.sourceforge.net/]?

Vypada zajimave.. diky za link.

>> Aplikace bude volat IGUI2. IGUI2 wrapuje gtk+. gtk+ wrapuje gdk.
>> gdk wrapuje xlib. teprve xlib konecne pohne prstem. Pritom je
>> to vsechno slinkovany dohromady do jednoho mamuta a kazda vrstva
>> se snazi aby to segfaultlo nebo aspon bezelo co nejpomaleji.
> 
> Taky pristup. Bohudik nepatri mezi mainstreamovy. Kdyby kazdy vsechno 
> programoval na co nejnizsi urovni aby to bylo rychle, tak by nemohl 
> pouzit jiz existujici kod (nebo by jej mohl pouzit s velkymi obtizemi) a 
> byli bychom stale v DOSu (nemyslim tim MS DOS). Nebo ty snad pouzivas 
> pro zapis na disk komunikaci s /dev/hd..? Vzdyt je to rychlejsi nez 
> pouzit funkci open nebo fopen a spriznene funkce, ne?

Srovnavate rozdilne veci. Implementace filesystemu je:
1) s desitky let ustalenym koncovym API
2) neobsahuje zbytecna interni zapouzdreni (vfs je uzitecny)
3) velmi efektivni (dusledek predchoziho)

> Navic -- lidska prace je draha a HW je levny. Vim, ze timto 
> konstatovanim si koleduju o flamewar, ale je to proste tak.

Mate plnou pravdu, kdybych nesouhlasil nebudu pouzivat Python.

>> Nebylo by lepsi owrapovat do pythonu jen samotnej xlib a nad tim
>> napsat widgety ciste v pythonu?

> Myslim, ze by vysledek byl pomalejsi a mene portovatelny nez GTK 

xlib nema nekompatibilni zmeny API kazdych par mesicu jako gtk+.

> wrapper. Uvedom si, ze volani funkce v Pythonu je relativne draha 
> operace a pro vykresleni jednoho tlacitka na nejnizsi urovni potrebujes 
> takovych operaci desitky nebo stovky, pokud chces dosahnout stejneho 
> vysledku jako pri pouziti GTK.

Zkousel jsem pyGtk i wxWindows na notebooku s 16MB RAM. Podle doby
na vykresleni trivialniho dialogu by behem setupu jednoho tlacitka
Python v pohode zavolal desitky tisic funkci.

Cisty python je podle mych zkusenosti cca 30x pomalejsi nez Ceckovy
kod ktery pouziva specializovane datove struktury pokud jde o brutalne
low level kod (treba parsovani binarnich dat, lookupy do hash tabulek
udelanych na miru atd).

Pokud se ale logika prehoupne na uroven dynamickych seznamu a prace
s vzajemne propojenym grafem objektu, je to uz tak 1:3-1:5. Mam zkusenost
ze python je prekvapive rychly, pomale je pouze:

1) vygenerovani a nasledne zpracovani vyjimky.
2) volani metod na objektech

To prvni mne prekvapilo, ale neni to problem pokud se vyjimky pouzivaji
pouze pro zpracovani skutecne necekanych chyb, nikoliv jako pouze dalsi
mechanismus pro vraceni vysledku z funkce.

To druhe se dalo cekat- dynamicky jazyk, nasobna dedicnost, a hlavne zadne
cachovani uz nalezench metod v objektech. Pokud by ale graficky toolkit
data "obalil" do objektu az na nejvyssi urovni tak to bude furt v pohode.

Napsal jsem treba SNMP modul ciste v Pythonu (s vyjimkou asn.1 parseru
/formatteru kterym je 200-radkovy extension v C), a bezi velmi vyrazne
rychleji nez snmpy ktery wrapuje velkou komplet ceckovou knihovnu net-snmp.

Volba programovaciho jazyka je podruzna. U soucasnych CPU je bottleneckem
pristup do pameti se spatnou lokalitou a temer nic jineho. Prave tohle 
je na
volbe programovaiho jazyka temer nezavisle. Pocet "hot" mist ktere je treba
drzet v cache zato roste umerne s poctem vsemoznych indirekci a "api 
wrapperu"!

Muj zaver je: minimum zbytecnych rozhrani a dobra volba tech potrebnych
=> efektivni kod.

-- 
Zdenek Pavlas