Nisam LINQ baš jako koristio jer je to samo verzija za $%##"! , onako iz prve mi se čini da je to samo primjer kako se mogu nadograđivati Generics-i.
Svake tablice imaju različite potrebe. Očekivati da za sve ima kračica je preambiciozno.
Nisam LINQ baš jako koristio jer je to samo verzija za $%##"! , onako iz prve mi se čini da je to samo primjer kako se mogu nadograđivati Generics-i.
Svake tablice imaju različite potrebe. Očekivati da za sve ima kračica je preambiciozno.
Nisam LINQ baš jako koristio jer je to samo verzija za $%##"! , onako iz prve mi se čini da je to samo primjer kako se mogu nadograđivati Generics-i.
Svake tablice imaju različite potrebe. Očekivati da za sve ima kračica je preambiciozno.
Istina, OrderBy je extension metoda na bilo koji objekt tipa IEnumerable<T>, znaci i za List<T>, IList<T>, array (iako tu ne vraca IEn.<T>), ...
Istina, OrderBy je extension metoda na bilo koji objekt tipa IEnumerable<T>, znaci i za List<T>, IList<T>, array (iako tu ne vraca IEn.<T>), ...
Takvih mjerenja sam vidio brdo vec, ali jos nisam nasao u praksi da netko koristi array ili listu od stotine tisuca objekata! To su gluposti.
LINQ na objekte u memoriji je poprilicno brz, i moze se koristiti svagdje osim za 3d i fizikalne proracune koji se izvrsavaju satima.
LINQ2SQL je sporiji od drugih metoda rada sa bazom (SqlReader), a dosta vremena ode na pretvorbu linq upita u sql upit, i na materijalizaciju objekata kada su podaci dobiveni iz baze.
Sa druge strane, LINQ2SQL moze podnijeti 100-200 000 unique posjeta dnevno na web server.
A sto se tice genericsa, oni se u compile time ionako zamjene za pridodjeljeni tip, tako da nema pada u brzini. Oni su napravljeni da se zamjeni enkapsulacija u "object" i da se dobije intellisense (strongly typed) objekata.
Takvih mjerenja sam vidio brdo vec, ali jos nisam nasao u praksi da netko koristi array ili listu od stotine tisuca objekata! To su gluposti.
LINQ na objekte u memoriji je poprilicno brz, i moze se koristiti svagdje osim za 3d i fizikalne proracune koji se izvrsavaju satima.
LINQ2SQL je sporiji od drugih metoda rada sa bazom (SqlReader), a dosta vremena ode na pretvorbu linq upita u sql upit, i na materijalizaciju objekata kada su podaci dobiveni iz baze.
Sa druge strane, LINQ2SQL moze podnijeti 100-200 000 unique posjeta dnevno na web server.
A sto se tice genericsa, oni se u compile time ionako zamjene za pridodjeljeni tip, tako da nema pada u brzini. Oni su napravljeni da se zamjeni enkapsulacija u "object" i da se dobije intellisense (strongly typed) objekata.
Evo upravo sam nekidan radio nesto slicno. Naime, imam Silverlight aplikaciju, i u Listboxu moram prikazati jako puno itema koji se onda pak mogu scrollati, selektirati, mjenjati i sl.
Za takve stvari nije dobra praksa da se sve ucita u listbox, to se tako ne radi, ne zbog brzine ORMa (u ovom slucaju LINQ2SQL), nego zbog samog listboxa.
Pogotovo je tu problem jer Silverlight komunicira sa serverom preko interneta i propusnost je relativno malena.
To se radi sa kontrolama koje podrzavaju Virtualisation, odnosno bindanje objekata na listbox (ili neki datalist, svejedno) koji se moraju prikazati, a ne svih. Ako tablica u bazi ima par tisuca recorda, sigurno ju necu ucitati cijelu odjednom. Ma i da ima vise od 50 redova ne bi to ucitavao odjednom...
To sve opet nema veze sa LINQom, jer nije on tu onaj koji usporava.
Učitavaš samo ono što vidiš, to je najbolja praksa.
Učitavaš samo ono što vidiš, to je najbolja praksa.
Nikada, bas nikada se ne ucitavaju podaci u memoriju da bi se sortirali ili slicno. Sve sta se moze mora se obaviti u bazi, sa SQLom. Treba razlikovati izradu LINQ upita gdje se tek stvara expression tree, i kada su vec podaci povuceni iz baze i onda nad njima radi LINQ manipulacija!
Za takve "slozenije" upite, ja koristim StoredProcedure, koje onda L2S mapira na metodu unutar DataContexta, pa dobijem strongly typed rezultat.
U firmi znam tu i tamo vrtit neke analitike nad logovima u bazi. A to je jedna tablica od gigabajt, sigurno. Da probam i sa najboljim ORM alatom zo ucitati i sortirati, kompjuter bi mi eksplodirao vjerojatno :)
I to je prica za jednog usera koji koristi app, zamisli da se njih 10-tak nakelji na server...
Druga stvar je svojsto L2S da uvjek radi Lazy Load, sto zna dovesti do velikom broja uzastopnih query-a na bazu. Za razliku od L2S, Entity Framework-u, koji isto koristi LINQ za upite, se mora explicitno reci sto da dohvati. I on ima nesto brzu materijalizaciju objekata u memoriji.
Nikada, bas nikada se ne ucitavaju podaci u memoriju da bi se sortirali ili slicno. Sve sta se moze mora se obaviti u bazi, sa SQLom. Treba razlikovati izradu LINQ upita gdje se tek stvara expression tree, i kada su vec podaci povuceni iz baze i onda nad njima radi LINQ manipulacija!
Za takve "slozenije" upite, ja koristim StoredProcedure, koje onda L2S mapira na metodu unutar DataContexta, pa dobijem strongly typed rezultat.
U firmi znam tu i tamo vrtit neke analitike nad logovima u bazi. A to je jedna tablica od gigabajt, sigurno. Da probam i sa najboljim ORM alatom zo ucitati i sortirati, kompjuter bi mi eksplodirao vjerojatno :)
I to je prica za jednog usera koji koristi app, zamisli da se njih 10-tak nakelji na server...
Druga stvar je svojsto L2S da uvjek radi Lazy Load, sto zna dovesti do velikom broja uzastopnih query-a na bazu. Za razliku od L2S, Entity Framework-u, koji isto koristi LINQ za upite, se mora explicitno reci sto da dohvati. I on ima nesto brzu materijalizaciju objekata u memoriji.
Iz moje perspektive to izgleda otprilike ovako
Dođe korisnik sa idejom (moj simultani prijevod) var r = from ladica1 in stol select kemijska orderby iskorištenost desc.
Eto, zbog želja korisnika znam lambda expressions, a zbog prijevoda imam LINQ koje sve zabindam na datagrid kontrolu, bilo web ili windows.
(da mi još to netko i pošteno plati)
A što se tiče brzine, ms u dokumentaciji obično koristi bubble sort što sumljam da stavlja u vlastite proizvode.
Neznam baš in-depth SQL server, ali znam da je cijela poanta u indeksiranju i optimiziranom-parametriziranom sortiranju.
Svatko izabere svoj stil. Na kraju je bitno, što očigledno znaš, da je kôd uredan, ali za kodera.
Možda nočas otkuckam neki iole vjerodostojan podatak o misteriju LINQ. Javim na kanalu rezultate.
.net framework za sort liste koristi Quick sort interno.
Bubble sort je dovoljno jednostavan da se moze koristiti u MSDN primjerima.
LINQ i lambda izrazi sadasnjost i buducnost c# i vb jezika. Ja radim s time svaki dan, ali i ucim isto svaki dan nesto novo, i svidza mi se smjer u kojem to sve ide. Jos bi se cak volio pozabaviti sa Ruby-em, odnosno IronRubyem. E to su tek lambda izrazi...
A da bi L2S dobro radio, trebaju biti ispravno postavljeni indexi, relacije, kljucevi i sve ostalo sto ide uz teoriju izrade baze podataka. Znanje ORM alata kao sto je Linq2Sql ne znaci da se mora vise znati posloziti i normalizirati baza. Dapace, ORM alati to ocekuju da bi mogli obaviti svoj posao!
E to su tek lambda izrazi...
Ako je pre sporo napravi kompliciranije! :}
Možda treba pregledati temelje. Bez obzira na iskoristivost LINQa činjenica je da je sortiranje Veliki Problem, jer da nije bilo bi nešto drugo :D
Ti bi našao nešto drugo, mislio si reći?:)
Ti bi našao nešto drugo, mislio si reći?:)
Ja bih bubble! :))))
Sad ozbiljno, zašto se uopće baviš ručnim sortiranjima ako dovlačenja iz baze možeš obavljati u praktički sortiranom obliku preko stvari koje su iznimno brze na serveru?
u FOR petljama sam korisitio Array.Sort(), a u FOREACH List<int>.Sort()
Start FOR Sorting: Start Time - 56385812 ticks
End FOR Sorting: End Time - 56387953 ticks
Score: 2141 ms
Start FOR int[10000] 56385812 ticks
End FOR int[10000] 56385812 ticks
Score: 0 ms
Start FOR int[100000] 56385812 ticks
End FOR int[100000] 56385828 ticks
Score: 16 ms
Start FOR int[1000000] 56385828 ticks
End FOR int[1000000] 56386000 ticks
Score: 172 ms
Start FOR int[10000000] 56386000 ticks
End FOR int[10000000] 56387953 ticks
Score: 1953 ms
Start FOREACH Sorting: Start Time - 56415906 ticks
End FOREACH Sorting: End Time - 56418156 ticks
Score: 2250 ms
Start FOREACH int[10000] 56415906 ticks
End FOREACH int[10000] 56415906 ticks
Score: 0 ms
Start FOREACH int[100000] 56415921 ticks
End FOREACH int[100000] 56415937 ticks
Score: 16 ms
Start FOREACH int[1000000] 56415937 ticks
End FOREACH int[1000000] 56416109 ticks
Score: 172 ms
Start FOREACH int[10000000] 56416187 ticks
End FOREACH int[10000000] 56418156 ticks
Score: 1969 ms
... za napraviti je test sa LINQ pa jel ima prijedloga za neki sort ?
Isti Sort algoritam, isto vrijeme izvršavanja.
Razlika je neprimjetna. Ja bi rekao da oni u mscorlibu koriste isti sorting algoritam. Vidim i da oba dvije klase upotrebljavaju IComparable interface za sortiranje.
Uostalom, ako je sortiranje toliko kriticna stvar u tom teskom proracunu koji radis, ljepo dodaj unsafe oznaku, i udri po pointerima, da vidis tek onda brzine!
Pregled animiranih sorting alrgoritama:
http://www.hanselman.com/blog/BackToBasicsAlgorithmsAndGoingBackToVirtualSchool.aspx
Usput, koju klasu si koristio za mjerenje? Trebala bi se koristiti Stopwatch, meni se cini da ona nije koristena u tvome slucaju posto vidim one tickove.
Evo tražeći po dokumentaciji da te razuvjerim nađem ovo za List<T>
This method uses Array.Sort, which uses the QuickSort algorithm.
Tako da Sort iz .Net 1 je identičan Sortu iz .Net 2 i cijeli post je uzalud.
Svejedno me zanima za LINQ, izgleda da OrderBy isto koristi QuickSort. Budem još malo pogledao.
TickCount za mjerenje. (Mislim da je dovoljno precizno).
Zanimljivo mi je da za 2 sekunde samo 10mb value typeova sortira.
Znači 5 mb/sec sortiranje.
Nekako mi se to čini sporo.
LINQ vjerojatno koristi isti Sort, jer u pozadini opet radi s istom kolekcijom, bilo ona array ili list, jer oba dvije nasljedzuju IEnumerable, a LINQ se kaci na taj interface.
Dali ti je aplikacija u Release nacinu rada?
I LINQ2SQL OrderBy prevodi u SQL, pa se sortiranje obavi na sql serveru. Prije si spominjao da koristis neke velike baze, pa je vazno to napomenuti.
I koristi StopWatch klasu, a ne tickcount, jer ona koristi hardwaresko mjerenje koje je preciznije od cistom oduzimanja dva vremena, sto koristi tickcount.
Jos jedna ideja: PLINQ (paraller linq), mozda on ima neki visenitni sort algoritam? Ili cak uzeti neku implementaciju GPGPU frameworka (CUDA.NET), pa se taj posao delegira grafickoj.
Benchmark sortinga liste, arraya i linq-a, ima graf na dnu stranice:
http://dotnetperls.com/Content/Sorting-String-Array.aspx
Jedna starija usporedba, ima .net 2 beta, iako su rucno napravili heap sort:
http://www.ddj.com/showArticle.jhtml?documentID=cuj0507bruckschlegel&pgno=3
Compile je u Debugu, ali mi nije najbitnije da bude najbrže već da vidim omjere i šta se događa.
Zato mi je sekundarno paziti na svaku instrukciju ili milisekundu, bitno da konzistentno provedem mjerenje i tek onda možda razmišljati o optimizacijama.
OK, od sada ću korisiti StopWatch!
PLINQ i CUDA ću pogledati.(za vikend)
Za to mi je i trebala usporedna lista brzine sortiranja. Da znam da binary sort radi 5mb/sec, što je smiješno malo.
Slijedeće ću staviti prave objekte da sortira i proći kroz OrderBy.
-Budem iste funkcije otkuckao i u SQLu, pa da usporedim SQL i LINQ. Možda LINQ2SQL ima smisla.
Pogledaj grafove na linkovi koji sam poslao - razlike izmedzu arraya, list<t> i Linqa gotova da i nema.
Takodzer, kazes da ti je cudno sto je sortiranje sporo, a nije ti vazno dali je aplikacija pokrenuta u Release ili Debug nacinu rada!? Pa u debugu je dosta sporiji, prebaci to.
sorting kod linq2sql ce obaviti sql server na bazi, i tu ce sve ovisiti kako su postavljeni indexi u bazi, i citanje podataka - dali se citaju sva polja ili se radi projekcija samo nekih, i naravno vrijeme potrebno za kreiranje zasebnih objekata (ne value tipova u heapu, nego reference tipova na stacku koji je sporiji od heapa!), i vrijeme potrebno za punjenje istih iz ado.net datareadera. Nemogu se usporedzivati kruske i jabuke.
Na grupi smo prije godinu dana imali demonstraciju LINQ2SQL-a u kontrastu s klasičnim SQL upitima. LINQ je u nekim situacijama brži.
Imam backup žive baze sa cca 150mb. Sa storama koje mogu zamjeniti LINQom i vidjeti real life scenario.
samo za tebe sam pokrenuo Realase i razlika na sortiranju najvećeg je svega 50ak ms (1900 vs 1950).
