Boj s modelmi v Qt4 - Epizóda 2 (diskuse)

[mirec]

Příloha:

• itemview.tar.bz2 (1475 bytů)

Sľúbený ukážkový program

[Jardík]

Zdravím. Potřeboval bych do listview dát 3 miliardy položek, jak toho docílím? Musím psát vlastní widget?

[mirec]

Nie len widget, ale aj celú MVC architektúru ;) Radšej ani nespomeniem aký typ sa používa na adresovanie v QVector-e ;)

[Ladicek]

Předpokládejme, že paměťové nároky na jednu položku v listview jsou 10 bajtů (ve skutečnosti to bude výrazně víc). To je 30 giga jen na ten listview – s dostatkem swapu je možná naalokuješ, ale to je všechno. Už jsi poslal ten životopis do SUSE?

[mirec]

Lenže tie dáta nemusia byť v RAM. Berme čiste teoretickú situáciu, že chceme postaviť hex editor, ktorého základom bude MVC z Qt. Vďaka tomu, že model môže načítavať dáta až keď sú potrebné bude editor pomerne rýchly a nenáročný. Lenže povedzme, že užívateľ chce na jednom riadku zobrazovať 4 bajty (teda spolu v hex zobrazení 8 znakov). To už sa dostaneme na celkom rozumných 12 giga. Ak si predstavíme, že niekto chce vyhrabať informáciu z konca 12 GB súboru (povedzme, že je to HD video s hlavičkou na konci) tak bude mať smolu len kvôli tomu, že bol použitý nesprávny typ pri adresovaní. Ale v podstate ani keby používali size_t nebola by to na 32 bitovom systéme výhra. Na adresovanie súborov tu máme offset_t, takže ani size_t by v takom prípade nebolo najsprávnejšie.

[Jardík]

Stejně nechápu, co je vedlo k použití typu int. Alespoň od Qt4 to mohli "opravit" a použít nějaký normálnější typ. Třeba size_t, intptr_t, uintptr_t, ptrdiff_t, ... prostě něco stejně velkýho jako pointer. Vždyť teď ani do toho QVectoru nenarvu 3mld intů (to je nějakých 12GB, takže s 16GB to není problém).

[Josef Kufner]

Dej tam (pokud možno reprezentativní) dva tisíce a doufej, že si toho uživatel nevšimne

[Heron]

Nevšimne, protože při listování se mohou dynamicky načítat další položky. Pak bude list obsahovat 2000 položek a uživatel si jich může prohlédnout klidně 3mld.

[xkucf03]

Na webu se taková situace běžně řeší pomocí stránkování – buď ručního (klíkání na čísla nebo další/předchozí) nebo automaticky – např. tabulka, dojedeš k jejímu konci a v tu chvíli se přes AJAX dotáhnou další záznamy. V klasické aplikaci to chce řešit podobně.

Navíc je nesmysl cpát do GUI (které je určené pro člověka) miliardy záznamů (ono i tisíce jsou dost), protože člověk si je stejně nikdy nepřečte. Takže tu stejně musí být nějaký další mechanismus, např. filtrování nebo hledání, aby ses dostal na rozumný počet položek. Je otázka, jestli má smysl někde zobrazovat i ten nefiltrovaný výsledek, který stejně nikdo číst nebude.

[mirec]

Ehm čo tak okteta? Hex editor schopný pracovať s pomerne veľkými súbormi, skokom na konkrétnu adresu, vyhľadávanie ... Na použitie s MVC ako vyšité.

[Jardík]

Naposledy, když jsem zkoušel oktetu, tak s velkými soubory (10GB+) pracovat rozhodně neuměla. Takový wxHexEditor to umí docela dobře.

[mirec]

A kto tu tvrdí, že vie? Už len kvôli MVC to vedieť nebude. Ja som len uvádzal príklad programu, kde by sa niečo väčšie ako int oplatilo použiť a nie je to len nejaký vymyslený umelý príklad.