JXP Commander a std::sort

17.7.2006 13:54 | Přečteno: 1462× | Linux

Jelikož padla spousta návrhů na použití std::sort k řazení, učinil jsem tak. Bohužel však nepociťuji ŽÁDNÉ zrychlení. Připadá mi to úplně stejně rychlé.

void FileInfoList::sort( int column, bool ascending )
{
	FileInfoComparator fic( column, ascending );
	std::sort( begin(), end(), fic );
}

bool FileInfoComparator::operator()( const PFileInfo& fi1, const PFileInfo& fi2 )
{
	if( fi1->isDots() ) return true;
	if( fi2->isDots() ) return false;
	if( fi1->isDir() && !fi2->isDir() ) return true;
	if( fi2->isDir() && !fi1->isDir() ) return false;
	int cmpRes = 0;
	off64_t size1,size2;
	time_t date1, date2;
	switch( sortColumn )
	{
		case FileInfoList::COLUMN_NAME:
			cmpRes = g_utf8_collate( fi1->getNameTitle().c_str(), fi2->getNameTitle().c_str() );
			break;
		case FileInfoList::COLUMN_EXT:
			cmpRes = g_utf8_collate( fi1->getName().c_str(), fi2->getName().c_str() );
			break;
		case FileInfoList::COLUMN_SIZE:
			fi1->getSize(size1); fi2->getSize(size2);
			if(size1>size2) cmpRes = 1;
			else if( size2>size1 ) cmpRes = -1;
			break;
		case FileInfoList::COLUMN_DATE:
			fi1->getDate(date1); fi2->getDate(date2);
			if(date1>date2) cmpRes = -1;
			else if(date2>date1) cmpRes = 1;
			break;
		case FileInfoList::COLUMN_ATTRS:
			cmpRes = g_utf8_collate( fi1->getAttrs().c_str(), fi2->getAttrs().c_str() );
			break;
		case FileInfoList::COLUMN_OWNER:
			cmpRes = g_utf8_collate( fi1->getOwner().c_str(), fi2->getOwner().c_str() );
			break;
		default:
			cmpRes = g_utf8_collate( fi1->getGroup().c_str(), fi2->getGroup().c_str() );
			break;
	}
	if(cmpRes == 0) cmpRes = g_utf8_collate( fi1->getName().c_str(), fi2->getName().c_str() );
	if(ascending) cmpRes = -cmpRes;
	return (cmpRes > 0);
}

       

Komentáře

[Kyosuke]

Myslím, že mnohem podstatnější je, _jak_ je to vlaatně rychlé. Nepodělíš se s námi o tuto informaci?

[Jardík]

Řekněme, že to není ani moc pomalé, ani moc rychlé. Zajímavé na tom je, že takto to řeší ATOL FM, ale jemu se to seřadí okamžitě. Sice používá k porovnání řetězců strcmp a já g_utf8_collate, ale tím to není. I když použiji strcmp, je na tom atol lépe. Možná to ani tak nezdržuje to řazení jako spíše smazání obsahu modelu a jeho opětovné naplnění. Ten model samozřejmě před těmito operacemi z treeviewu odpojuji.

[Kyosuke]

Chceš tím naznačit, že to tady už třetí blogpost ladíš na výkon a ještě jsi to ani jednou nevyprofiloval?

[Michal Vyskočil]

Jakto? Přece proběhl přepis z gtkmm (moc pomalé) do gtk

[Kyosuke]

Reaguju konkrétně na větu „Možná to ani tak nezdržuje to řazení“... Někdy nestačí myslet a je třeba vědět. Kdepak, bez profileru při ladění výkonu nehnu prstem.

[Michal Vyskočil]

Já ti rozumím, jenom jsem poukázal na jednu "optimalizaci", která už proběhla . Taky nerad přepisuju kód. o němž 100% nevím, že je to ten kousek, co mě zpomaluje.

[Michal Kubeček]

Mám to chápat tak, že při požadavku na přeřazení znovu načítáte celý obsah adresáře a na každý soubor voláte stat() nebo lstat()? Pak by mne nepřekvapilo, pokud by problém byl skutečně tady a ne v samotném řazení seznamu.

[Jardík]

Ale blbost. Nevolám. Pouze při vstupu do adresáře - což se děje i při spuštění programu. Myslel jsem to tak, že musí ještě navíc plnit pár sloupců v treeviewu - a to také zdržuje.

[Michal Kubeček]

Tak to nemůžu sloužit, tak dalece Gtk neznám. Takže mi nezbývá než se připojit k doporučení, abyste na to vypustil profiler, protože jinak můžeme jen prázdně spekulovat.

[elviin]

Zkousel jsi to s std::set/vector? Do toho kontejneru ukladas cely objekty nebo (chytry) ukazatele? Vypada to, ze cely objekty. Mozna v tom bude urcity zrychleni, protoze jestli to mas ulozeny ve vektoru, pak se musi serazena posloupnost kopirovat, resp se kopiruji i objekty. Nebylo by lepsi radit podle ukazatelu?:

typedef shared_ptr<PFileInfo> PFileInfoPtr_t;
typedef std::vector<PFileInfoPtr_t> fileContainer;

[elviin]

nemyslel jsem set ale list.

[Jardík]

class FileInfoList: public std::vector<FileInfo*>{
...
}

Drží tedy ukazatele. PFileInfo je jen typedef na FileInfo*, abych se vyhnul něčemu jako const FileInfo*& v tom operátoru ().

[elviin]

Aha! diky.

[elviin]

Jeste neco k tomu napisu. Data jsou proste nekde ulozena. Na ty data ukazujes. A ty ukazatele (v jakekoliv forme) jsou ulozene ve vektorech (treba nebo setech nebo ja nevim co) a kazdy vektor je vytvorenej na zaklade odlisneho zpusobu razeni (objektu kopmaratoru). Jak to dole pise happy barney.

Ale jakej by byl zisk nevim. Mne ten switch prijde takovej jednoduchej, ale zase nadruhou stranu si muzes drzet serazene std:sety (mozna std::vector) a vzdy jen pouzijes ten, ktery proste chces a potrebujes.

[happy barney]

problem nebude v algoritme, ale v komparatore

preco neskusit (ako som navrhoval)
- extra komparatory (triedy) pre kazdy typ stlpca
- vyhodit . a .. z filelistu

navyse, nie je doriesena otazka, ako sortovat v pripade rovnosti kriteria (datumy, velkosti, ...)

[Jardík]

To mně na tom nejvíce štve. V případě std::sort nemám možnost říci, že jsou položky "stejné". Musím to řešit tak, že pokud jsou, musím je setřídit dle jména. Před tím jsem je prostě nechal tam, kde byly. V komparátoru chyba nebude - v atolu je to úplně stejně a je to setřízeno okamžitě.

[Michal Kubeček]

Tu možnost samozřejmě máte: položky jsou ekvivalentní, pokud není a<b ani b<a. Proto se to jmenuje strict weak ordering.

[happy barney]

to by muselo ale byt

return cmpRes == 0;

vlastne i to moze byt dovod tej "pomalosti"

[happy barney]

oprava, samozrejme !=

[Kníže Ignor]

tak to snad ne, ten komparátor odpovídá na otázku, jestli je ta dvojice prvků v té relaci, takže se v tom returnu nic měnit nemusí

[happy barney]

hopla
no nic, uz si konecne musim dat abclinuxu.cz medzi blokovane stranky v case 6:00 - 18:00 )

[Kníže Ignor]

tož, když už je ten komandér tak zaměřenej na to třídění, nemohl by si pro každej adresář pamatovat zvlášť, jak se v něm má třídit, pamatovat by si moh i další věci - třeba způsob zobrazení, jaké sóbory mají být skryté atd.

[s0]

tak jsem si to cvicne vyzkousel v Qt a nacteni a setrideni /etc mi vychazi na cca 49ms. Vcetne vypisu do statusbaru a na konzoli. Se mi nezda, ze by to melo byt v Gtk pomalejsi...

[Feyd]

gtk je pomalej rosolovite se prekreslujici sh*t

[disorder]

hehe, vdaka za podstatnu informaciu :)

btw skusil som si prekreslovanie menu v opere (Qt) a sylpheed-claws (Gtk+) a opera nestihala vypisovat viac nez prvu polozku :)

[Filip Jirsák]

To je opravdu komentářová perla. Ta přesná fakta, vybroušené formulace… Jestli to byla jen záminka, aby se zobrazilo vedle vašeho jména tlačítko blokovat a mohli jsme ho snadno použít, stačilo nechat komentář prázdný…

[Jardík]

Proboha. /etc? Tam je skoro prd. Já tam mám 143 položek. V tom commanderu jich mám v seznamu 2000 :) Zkus třeba /usr/bin - 1523. A nezkoušej jen výpis souborů. Zkus si přidat velikost, práva, vlastníka, skupinu - ono tě to pak docela pozdrží.

[s0]

/usr/bin 1946. Vypisuju tam jmeno souboru, f|d, cas posledni modifikace. Vic se mi nechce delat ;)

20:08:39:458    start
20:08:40:419    end

samozrejme, ziskani celeho vypisu rwxrw-rw- by to urcite zpomalilo, ale trideni mi QListView dela uplne sam - krome trideni podle data modifikace. Tam se musi napsat jedna porovnavaci funkce.

[Sinuhet]

Drobna pripominka k deklaraci te metody:

bool FileInfoComparator::operator()( const PFileInfo& fi1, const PFileInfo& fi2 )

Pokud definice PFileInfo vypada nejak takto

typedef FileInfo* PFileInfo;

tak to dohromady nedela to, co nejspis prepodkladate. Vyleze z toho totiz reference na konstatni ukazatel na objekt FileInfo. Neboli primo fi1 menit nelze, ale objekt, na ktery ukazuje, ano (*fi1 = *fi2 projde). A take je zcela zbytecne cpat na ukazatele jeste reference. IMHO spravna deklarace by mela vypadat takto

bool FileInfoComparator::operator()(const FileInfo* fi1, const FileInfo* fi2 )