En kollega till mig sa att han mätt lite och det visade sig att den var 422% långsammare än att använda vanliga klasser och lagrade procedurer om man körde ett anrop 10.000 gånger från applikaionen. Jag tror att denna klass är väldigt bra att använda vid enklare applikationer men tror inte den håller i en mer komplex miljö, med flera användare och med fler utvecklare samtidigt.

Hur är er syn på detta?

Jag har nu inte testat LINQ to SQL, men en anledning till att det är slöare kan vara för att den inte kan skriva en effektiv SQL sats och/eller att den måste ladda in fler objekt än nödvändigt och filtrera dem med LINQ to Objects.

Självklart är det en liten overhead men prestandan beror säkert på hur väl den kan skriva SQL från frågan.

Visst är det så, prestanda hänger ju ihop med flera faktorer. Finns det någon som bygger system baserat på detta till kunder som ni känner till. Jag har hört några projekt som kör detta - vad säger kunderna, vad säger ni och vad har ni för erfarenheter om detta?

Jag håller på med detta nu för första gången i ett privat projekt och har inte gjort några jättekomplexa körningar eller så än. Men utifrån det jag gjort verkar det ta en stund när man väl startar applikationen, men sen går det fortare. Kan kanske vara MySql-syndromet, första gången det körs är det slött, sen går det undan. Men har inte gjort tester på det än så ska inte säga för mycket.

Men hur det blir beror ju på hur man lägger upp DAL också. Du kan ju köra med klasser direkt mot tabellen och mot SP. Kör man mot tabellen så jobbar den med samtlig data och det tar ju på krafterna. Kör man mot SP kan man begränsa datan betydligt och det blir snabbare.

Men det stora syftet tror jag nog är mer att få en enklare "vackrare" kod än ren prestanda då det är som ni säger, inte en ultimat optimerad kod.

<b>422% långsammare</b>
Det märks när folk inte kommer från forskning... =)

<b>>Men det stora syftet tror jag nog är mer att få en enklare "vackrare" kod än ren prestanda då det är som ni säger, inte en ultimat optimerad kod.</b>
Den stora skillnaden är att eftersom linq blir funktionellt och därmed lazy så går det att optimera så innihelvete mycket mer, sen om det inte görs är det ju en annan sak (men då ska man också ha klart för sig att man ska undvika att ha massa "vanlig kod" emellan, då försvinner hela den poängen.

Min uppfattning av LINQ är att det finns och man kan göra en del med det. Eftersom LINQ finns för Object, XML och SQL m.fl. så finns det inte en chans i världen i mitt huvud att den skulle vara effektivare än en ren SQL-sats mot en databas. LINQ to SQL om den görs om till en ren SQL-sats, som sedan körs mot databasen borde logiskt sätt ta några milliekunder längre tid eftersom den först ska konverteras till ren SQL för att sedan köras mot db:n.

LINQ to XML är en fördel då man snabbt kan plocka in en XML-fil i en repeater med lite kod, t.ex. om man enkelt vill visa ett RSS-flöde på sin sida och begränsa det till x antal poster. Så att här har man fått ett enkelt verktyg i LINQ.

Jag tror inte att man ska ersätta t.ex. en ren SQL-fråga mot db:n med LINQ to SQL bara för att det finns, utan använda LINQ när man kan dra nytta av fördelar som den ändå kan ge, merän att ha "samma" syntax för att läsa in en XML som en SQL mot t.ex. en repaetar. SQL:en bör istället flyttas mot SP:s, än att lägga över dessa i LINQ to SQL.

Fan det är fascinerande att så få ser till det faktum att LINQ ligger en nivå över vanlig imperativ programmering, och att det i sin tur också tvingar C# och VB.NET att äntligen mogna som språk och bli kraftfullare.

Huruvida LINQ är mer effektivt eller inte handlar om ifall deduktionen som kan göras bättre på kompilatorsidan är på db-sidan. (och där har vi framför allt en gratis laziness på vilken nivå som helst)

Fördelen med funktionella inslag i språken är lika stora som att gå från gotos till loopar.

Jag blir förvånad över uttrycket "422% gånger långsammare". För att verifiera det krävs mer fakta.

1) Hur var scenariot?
2) Vad användes för mätmetod
3) Använde man L2S optimerat, användes tex loadspans och precompiled queries.
4) Vad användes för LINQ frågor? LINQ och T-SQL skiljer sig väsentligt i vad som är "best practices" vad gäller frågeställning.

Det finns ett flertal riktiga undersökningar som är gjorda av tex KTH som visar på en viss prestanda skillnad, men en som är försumbar om man väger in produktiviteten och den ökade underhållsbarheten som kommer från ett OO system.

F-Ö var det samma diskussion när de första query motorerna kom till databaserna. De var ju flera 100% långsammare än att själv hämta den information man ville ha via file I/O mot databasfilern.

Alla vet nog vilken av de teknikerna som är dominerande idag. Den som ökar produktivitet, gör det enklare att underhålla och är mer optimerad för användning än extrem prestanda.

Sen skulle jag vilja hävda att de som stirrar sig blint på prestandan börjar i fel ände, prestanda optimering gör man när man har ett problem. I första hand skall man fokusera på att leverera funktionalitet som bidrar med nytta och det på ett enkelt och kvalitativt sätt.

Linq2Sql har faktiskt riktigt bra och optimerad SQL kod (så på profilern och kontrollera) men det gäller endast enklare frågor där man inte har många Joins.

Problemet kommer när man vill ha ut information i flera under objekt till ditt objekt, då kan inte L2S hantera detta genom att skapa en SQL sats som kan få ut alla information på en gång utan man börjar skicka en ny SQL-fråga för varje refererat objekt som man vill ha. Och har du då en lista med kunder och dessa kunder har orders och dessa order har orderlines och dessa orderlines har artiklar och du vill ha ut all den information på en gång (inte så vanligt men det finns tillfällen) så blir det en j-vla massa frågor mot databasen, där andra ORM klara det på typ 4-5 frågor vilket kommer göra stor skillnad prestandamässigt.

- M

På Patriks kommentar om att man börjar i fel ände med prestanda tycker jag bestämt att det är fel. Jag ser hellre att bygga ett system som från början inte får problem med prestanda än att senare inse att man valt fel teknik eller inte tänkt på detta utan fått riva upp och göra om arbetet. Det känns oseriöst ur ett perspektiv där vi som konsulter skall förutse om det skulle kunna bli ett problem.

Givetvis är det ju idag billigt med hårdvara för att öka prestanda, men fortfarande så tycker jag som arkitekt eller utvecklare att bygga in sig i hörn är något som inte får förekomma. I så fall måste man upprätta en dialog och ett godkännande från kunden att just prestanda inte är något issue nu som i framtiden när designen görs. Kunden måste informeras om att man gör avkall på prestandakrav så att inga missförstånd sker.

>Fan det är fascinerande att så få ser till det faktum att LINQ ligger en nivå över vanlig imperativ
>programmering, och att det i sin tur också tvingar C# och VB.NET att äntligen mogna som språk och bli
>kraftfullare.
>Huruvida LINQ är mer effektivt eller inte handlar om ifall deduktionen som kan göras bättre på
>kompilatorsidan är på db-sidan. (och där har vi framför allt en gratis laziness på vilken nivå som helst)

Jag förstår vad du säger och håller med när det gäller linq i allmänhet.
Problemet med linq2sql är att det innehåller ett externt beroende som är svårt att få grepp om.

Med linq2objects är det lätt att uppskatta vilken komplexitet ett visst uttryck har. I linq2sql tillkommer att data måste skyfflas fram och tillbaka till databasen. Hur vet man om en join eller gruppering görs i databasen eller i applikationen vilket har stor inverkan på prestanda? I framtiden spelar det förhoppningsvis ingen roll men det känns som det är en bit kvar dit.

Jag använder linq2objects och linq2xml dagligen men jag vågar ännu inte riktigt lita på linq2sql. Tänker hela tiden på hur den genererade sql-satsen kommer att se ut och då kan jag ju lika gärna skriva den direkt själv.

När databaserna börjar anpassas för SSD diskar kommer vi att antagligen att få se stora förändringar i hur sql:en skall byggas ihop. Där tror jag att linq2sql:s abstraktion kommer att spela en stor roll.

<b>På Patriks kommentar om att man börjar i fel ände med prestanda tycker jag bestämt att det är fel. Jag ser hellre att bygga ett system som från början inte får problem med prestanda än att senare inse att man valt fel teknik eller inte tänkt på detta utan fått riva upp och göra om arbetet. Det känns oseriöst ur ett perspektiv där vi som konsulter skall förutse om det skulle kunna bli ett problem. </b>

Kanske jag som tolkar Patrik annorlunda, men jag håller med Patrik i att det är bättre att bygga ett bra felfritt system för att sen kanske leta optimeringar. Hellre ett långsammare felfritt system än ett snabbt system fullt med buggar.

Hans, vem säger att man skall bygga system med buggar? Nu vinklar du diskussionen med något helt annat så det blir väl inte riktigt jämförbart? Prestanda är inte samma sak som buggar ;)

Det säger ju sig självt, ju snabbare du kör på motorvägen desto mer troligt är det att du gör ett fel och kraschar.. Ju snabbare du kör bitarna i processorn, desto större risk att de svänger fel och kraschar i någon atom ;)

Nja, var inte så jag menade heller :)
Många koncentrerar sig så mycket på att bygga snabba system istället för att i första hand koncentrera sig på stabiliteten. I min värld är stabiliteten primär och prestandan sekundär. Har tyvärr sett för många exempel på motsatsen.

<b>>Jag förstår vad du säger och håller med när det gäller linq i allmänhet.
Problemet med linq2sql är att det innehåller ett externt beroende som är svårt att få grepp om.

Med linq2objects är det lätt att uppskatta vilken komplexitet ett visst uttryck har. I linq2sql tillkommer att data måste skyfflas fram och tillbaka till databasen. Hur vet man om en join eller gruppering görs i databasen eller i applikationen vilket har stor inverkan på prestanda? I framtiden spelar det förhoppningsvis ingen roll men det känns som det är en bit kvar dit. </b>
Trevligt att få någon att diskutera med om det som är det intressanta... =)

Jag håller helt med vad gäller l2s, och även jag använder bara l2o (dock inte för xml eftersom jag inte använder xml öht just nu). Att l2s inte är optimal idag har jag nog inte påstått.

Poängen är ju mer att l2s har så mycket större potential, och möjlighet att planera in körningar (och även maskinellt logga och göra uppföljningar efter hand) på helt andra sätt än fasta sql-anrop.

<b>Tänker hela tiden på hur den genererade sql-satsen kommer att se ut och då kan jag ju lika gärna skriva den direkt själv.</b>
Tyvärr hävdar jag att detta är ett problem med utvecklingsmiljön snarare än något annat. Istället för att göra en editor som ska hålla en i handen och rädda en från svår kod hela tiden, så borde vs fokusera på att vara en bra editor, och ska vi ha intellisense så borde den även kunna visa den genererade sqlsatsen direkt.

Jaja, nu gick detta visst över till en rant mot vs. Skit samma.

Jag håller med Patrik.

Att börja optimera först är ett antipattern.

Det behöver inte betyda något om en teknik är långsammare än en annan, så länge den är _snabb nog_.

Ruby är säkert tusen ggr långsammare än ASM, men det används ändå med stor framgång..

//Roger

Buggar... hmm

Buggar är bara odokumenterade funktioner. ;)

Aropå använda Linq To SQL, så använder vi det i samtliga skarpa webbprojekt vi har.
personligen skulle jag vilja köra NHibernate, men det är inte jag som bestämmer där.

Sen är iofs Linq TO SQL effektivt i den mån att det går snabbt att ta fram ett datalager, till skillnad från att skapa samtliga entitetsklasser för att sedan mappa dem mot data.

För mycket handlar om tid, och kanske inte så mycket om perfektion.

Ang. prestanda så blir man först berörd när tiden överstiger ett visst antal sekunder. Vissa saker har man tålamod att vänta på, vissa saker ej.

Men sant, att börja med optimering av prestanda är felväg att gå.

0. ) Bestäm teknologi utifrån kraven på produkten (Kunna byta databashanterare osv)
1. ) Skapa en sprint för produkten
2. ) Testa sprinten (funktionalitet, användarbelastning m.m.)
3. ) Uppfyller inte sprinten kraven, modifiera. (ex. prestanda, design etc.)
4. ) Släpp sprinten.

Förväxla nu inte sprinten med SCRUMS sprintar. Vill bara syfta på någon form av funktionalitet i ett system.

Sen är det ju inte alltid det är koden det är fel på, ibland kan det ligga i dåligt skapade databaser med dåliga index osv.

"Jag ser hellre att bygga ett system som från början inte får problem med prestanda än att senare inse att man valt fel teknik eller inte tänkt på detta utan fått riva upp och göra om arbetet. Det känns oseriöst ur ett perspektiv där vi som konsulter skall förutse om det skulle kunna bli ett problem."

Självklart skall du inte bygga något med uppenbara prestandanackdelar vad jag menar är att du skall inte välja bort en teknik för att den är långsammare innan du vet vad du har för prestandakrav eller om prestandan är god nog för det projekt du bygger. "Problem med prestandan" är väldigt subjektiv. Det är också därför jag undrar över "testet" som gjorts, jag kan utan problem göra ett "test" som visar att sprocar är 422% långsammare än L2S. Allt ligger i scenariot och hur man använder sig av tekniken man vill testa.

Om vi alltid skulle välja det snabbaste alternativet hade vi aldrig lämnat maskinkod och assembler för det är garanterat 422% snabbare än .NET kod.

Jag levererar hellre mjukvara som fungerar, är förberedd för förändring (så att man inte behöver "riva upp" för att optimera) och ger det affärsvärde som kunden beställt än ger mig in i tekniska hårklyverier.

Om du använder rätt teknik, som tex L2S eller NHibernate, och nyttjar bla enhetstester och andra kvalitetshöjjande åtgärder som tex Continous integration så är prestanda optimering aldrig ett problem i de få tal fall det kan behövas när du använder en ORM.

Jag skulle hellre se att utvecklare började fokusera på att leverera kvalité isf att hyperoptimera i onödan.

Det finne en sanning som hängt med sen 70-talet (beskrivs i boken "the mythical man month" något som alla som är seriösa med utveckling borde läsa):

"Premature optimization is the root to all evil"

Han som sa det var med och byggde någon tidig version av Unix, gissa om prestanda var viktig för dem.

"men tror inte den håller i en mer komplex miljö"
Som en sidonot: Jag skulle vilja hävda att jag sett alldeles för många fall där stored procedures och egen skriven SQL kod inte hållt för komplex miljö. Ju större systemet är desto snabbare kommer man in i problem med underhåll i sådana lösningar.

Underhållsvänlighet är den aspekt jag fokuserar på. Ett system som är svårt att underhålla är dyrare över dess livstid för kunden. Inför den här aspekten är tex L2S och andra tekniker extrema i att tillföra nytta.

@Patrik:
<b>
Jag skulle vilja hävda att jag sett alldeles för många fall där stored procedures och egen skriven SQL kod inte hållt för komplex miljö.
</b>
Vad kan man dra för slutsatser av detta?

1. Skriver man koden (egenskriven) rätt från början så håller det för den komplexa miljön. Det känns här som om det är underförstått att L2S gör så. Kan L2S så kan man det även som egenskriven (IMHO).

2. Det du beskriver att du sett många exempel på kanske mer är ett symptom på att utvecklare ofta får hålla på med saker som dom inte riktigt behärskar. Kanske inte ovanligt att dom är i alla lager och "rotar". Vilket ofta leder till att man är lite halvbra på allting.

"1. Skriver man koden (egenskriven) rätt från början så håller det för den komplexa miljön. Det känns här som om det är underförstått att L2S gör så. Kan L2S så kan man det även som egenskriven (IMHO)."

På ett sätt menar vi samma sak men på ett annat inte, ja L2S och dess motsvarigheter kan generera samma T-SQL som du själv kan skriva. Det är dock inte där problemet ligger. Jag vill hävda att långa sidor med T-SQL är svårare att underhålla än ett objektorienterat system.

T-SQL saknar möjlighet att skapa flexibel och undehållsvänglig kod på den nivå som jag vill ha i de system jag bygger. Genom att använda L2S eller liknande slipper jag hantera T-SQL koden och kan istället fokusera på att bygga mitt system utefter de objektorienterade principer som uppfyller mina krav på underhåll, tydlighet och flexibilitet.

"2. Det du beskriver att du sett många exempel på kanske mer är ett symptom på att utvecklare ofta får hålla på med saker som dom inte riktigt behärskar. Kanske inte ovanligt att dom är i alla lager och "rotar". Vilket ofta leder till att man är lite halvbra på allting."

Nej det jag försöker beskriva är att det finns ett tak en "cap" där T-SQL och sprocar inte längre klarar av att hantera komplexiteten utan att det blir ordentlig spaggetti av alltihop.

Det här har de stora DB leverantörerna addresserat för komplicerad rapportering genom att ta fram andra språk och tekniker för avancerad BI, som MDX tex.

Samma gäller för seriösa bussiness applikationer, där skall vi lägga tid och fokus på verktyg som ger oss den mest optimala koden för problemet.

Ok Patrik, nu förstår jag vad du menar.
När du skrev <b>egen skriven SQL kod inte hållt för komplex miljö</b> så fick ordet <b>hållt</b> mina tankar att gå åt andra håll än underhållsvänligheten som du hade som fokus, och nu förklarade.

:)