🚀 go-pugleaf

W dniu 2014-07-31 00:59, Arivald pisze:
> On 2014-07-30 20:25, Ciekawy wrote:
>>
>>> A co do takiego pola geometrii, lub wręcz całych rekordów bez PKEYa, to
>>> o ile dane się nie duplikują to jako PKEY możesz użyć skrótu SHA-1 z
>>> całego wiersza (160 bitów, więcej niż GUID)
>>>
>> Przemyślałem sprawę, muszę zrobić sobie listę buforującą klucze. Sprawę
>> załatwia mi TList<string> Index to dla mnie klucz Integer.
>
> Daj spokój TList. To się nie nadaje na cache bazy danych, już przy kilku
> tysiącach rekordów TDictionary będzie ogólnie szybsze, biorąc pod uwagę
> szukanie, sortowanie i realokacje pamięci, drogie dla TList. Dla
> milionów rekordów TList nie ma żadnych szans.
Hola, hola!
Sprawdzałeś wyszukiwanie za pomocą BinarySearch (IndexOf wyszukuje 
sekwencyjnie - i dziwicie się, że to  jest wolne...)?
Sprawdzałeś TList z implmentacją IEqualityComparer (porównywacz z 
hashem, używany w TDictionary)?
Problem wykracza poza proste używanie obiektów i komponentów.
A moim zdaniem - wykracza poza (ale chyba niewiele) dyskusje na grupie, 
wszyscy za mało wiemy o otoczeniu problemu.
Efekt może być taki, że nasze rady to zdadzą się psu na budę, bo może 
wystarczy zastosować jakiś sprytny algorytm i po sprawie.
Ale tego nie wiem.

>> Jedyny temat
>> to to, że TList jest wolniejsza od TDictionary przy sprawdzaniu czy dany
>> element nie znajduje się na liście, a musi sprawdzić zanim go doda:
>> TDictionary<>.containKey
>> TList<>.IndexOf <>-1. (dla 30 000 rekordów dla TDictionary to 1 sek dla
>> TList 7 sek).
>> Z kolei w TList wygodnym jest to że mogę dobrać się do elementu za
>> pomocą jego indexu. TDictionary takiej opcji nie posiada.
>
> Za to posiada dostęp po kluczu, o w miarę stałej prędkości.
> Także stały czas dodawania/usuwania rekordu.
>
> W TList problemem dostępy po kluczu jest nie tylko czas indexof(), ale
> też jego charakterystyka, ponieważ generalnie najczęściej czyta się czy
> modyfikuje ostatnio dodane rekordy.
>
>>
>> Co do stosowania klucza typu Integer, zostawiam to u siebie, powyższe
>> rozwiazanie chcę stosować tam gdzie takiego klucza nie ma.
>>
>> Pozdrawiam Ciekawy.
>>
>> Może jest coś co łączy w moim przypadku atuty i TDictionary<> i TList<>?
>
> Ja bym zrobił zupełnie inaczej.
> Robisz sobie embedded SQLite (lub firebird), i składujesz tam dane, i
> korzystasz z potęgi SQLa + TDataSet. Oczywiście będzie to
> nieporównywalnie wolniejsze niż iteracja po TDictionary czy TList... Ale
> SQL załatwia Ci od ręki filtrowanie, sortowanie i łączenie danych, na
> pewno szybciej niż byś to wydziergał na TList.
To samo załatwia TList (filtrowanie, sortowanie), w standardzie od 
Spring4D, a nie w standardzie własne - ale to proste do napisania jest 
(iteracja + sprawdzenie warunku za pomocą metody anonimowej). Szybsze 
niż wydzierganie bazy danych w SQLite...
Ale ważniejsze jest to, że będzie to WIELOKROTNIE szybsze od bazy danych.
Robiłem coś podobnego jakiś czas temu - po dwóch dniach walki okazało 
się, że baza danych to wolny muł...

> SQLite umożliwia tworzenie tabel "tylko w pamięci", więc jak masz
> gigabajty ramu do dyspozycji to operacje na dysku nie będą Cię spowalniać.
Moim zdaniem, trzeba trochę pokombinować, żeby było dobrze. Samo "weź 
SQLLite i będzie świetnie" lub "TDIctionary załatwi srpawę" to takie 
rady w stylu wujek dobra rada.

-- 
wloochacz