Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1

    Linq ... il rovescio della medaglia?

    Oggi ho usato Linq per la prima volta. Mi avevano detto di usare Linq per l'XML e dopo un paio di letture mi son messo giù a scrivere sql per interagire con liste di ogni tipo, come secondo parametro di foreach e altro ancora.

    Ora, quanto questo Linq incide sulle performances? Perchè tra lambda, runtime Anonymous assignment, clausole performate appunto in lambda ed altro ... mi son subito preoccupato delle performances.

    Allo stesso tempo un collega mi ha immediatamente detto: ok, su quegli if che avevo scritto io potevo mettere breakpoints e analizzare il tutto, su Linqu in query per filtrare come faccio a capire filtri e a debuggare?

    Io son certo ci siano metodi appositi per monitorare Linq ma non ho risposto, dato che conoscevo l'argomento più per sentito dire che altro ... ebbene, come sunto, mi dite quali sono i difetti di una classe, metodo, applicazione, scritte interamente in Linq? (o con uso massiccio, per intenderci)

    Grazie
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  2. #2
    Utente di HTML.it L'avatar di tekanet
    Registrato dal
    Oct 2001
    Messaggi
    299
    Innanzitutto, doveroso fare una distinzione: ciò di cui stai parlando è Linq to SQL, l'estensione di Linq orientata all'interrogazione di database MS SQL Server. Linq è molto di più e serve a molto altro.

    Detto questo, se le performance sono un requisito cruciale del tuo programma, allora forse Linq2SQL non è la scelta perfetta. Però c'è da valutare attentamente cosa intendi per performance. Ho utilizzato stored procedures per più o meno tutto ciò che interessa il dialogo programma-db fino a un'annetto fa. Ho accolto con entusiasmo Linq2SQL e con il tempo credo di essere giunto ad una via di mezzo. Linq2SQL è semplicemente imbattibile per le operazioni CRUD: non c'è a mio modo di vedere un altro modo per selezionare, inserire, modificare e aggiornare un singolo dato efficace quanto Linq2SQL. Questa sorta di OR/M però perde parecchio quando si tratta di operazioni massive di insert, update o delete. Ma quante volte all'interno di una classica applicazione di gestione sono coinvolte queste operazioni? Poche, in percentuale: in questi casi Linq2SQL mappa tranquillamente delle stored come metodi. Può essere una via.

    Chiudo il post (ma sarei felice di sentire anche il parere di altri e approfondire) dicendo che (secondo me, purtroppo) Microsoft ha già da tempo detto che non approfondirà lo sviluppo di Linq2SQL: tutto è spostato su Entity Framework e pare che la fine del predecessore sia già segnata dalla partenza. I motivi sono tanti, anche se non mi sento di condividerli tutti..

    tk

  3. #3
    Originariamente inviato da tekanet
    Innanzitutto, doveroso fare una distinzione: ciò di cui stai parlando è Linq to SQL, l'estensione di Linq orientata all'interrogazione di database MS SQL Server. Linq è molto di più e serve a molto altro.
    ... er ... veramente no, io parlavo di Linq su dati, senza nemmeno considerare il db.
    codice:
    foreach (
        var attrib in
        (
            from attrib in View.Entity.EntityType.Attributes
            where !String.IsNullOrEmpty(attrib.DisplayName)
            where !String.IsNullOrEmpty(attrib.ControlType)
            select attrib
        )
    ) {
        ....
    }
    ecco, con un foreach in Linq mi sono risparmiato due if e volendo posso subfiltrare, ordinare, raggruppare, il tutto da una lista di attributi non connessa al database.
    Un po come
    codice:
    Team juve = new Team('Juventus', 41);
    ...
    Team[] league = new Team[] {juve, milan, inter};
    foreach(Team classifica in (from team in league orderby team.score select team))
        Response.Write("Squadra: " + classifica.name + " Punti: " + classifica.score);
    credo comunque tu abbia gia' risposto alle mie domande ... quindi Linq e' nato e morto in un paio di anni? Peccato
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #4
    Utente di HTML.it L'avatar di tekanet
    Registrato dal
    Oct 2001
    Messaggi
    299
    Originariamente inviato da andr3a
    ... er ... veramente no, io parlavo di Linq su dati, senza nemmeno considerare il db
    credo comunque tu abbia gia' risposto alle mie domande ... quindi Linq e' nato e morto in un paio di anni? Peccato
    Sorry, dicevi "mi son messo giù a scrivere sql" ..

    Comunque Linq2SQL è si praticamente dall'inizio già al capolinea (salvo eventuali dietrofront dovuti ad una comunque folta schiera di estimatori).

    Linq invece, la parte di linguaggio che riguarda l'interazione con gli (insiemi di) oggetti, è tutt'altro che sulla via del tramonto: la reputo una delle più grandi funzionalità mai realizzate in ambito programmazione e certamente la pensano così anche a Redmond. Quindi, ricapitolando in breve:
    - per l'accesso ai dati, se vuoi essere lungimirante, scegli Entity Framework (o un altro OR/M o, visto che nessuno ti costringe, i classici meccanismi di ADO.NET)
    - per l'interrogazione di oggetti e collezioni, Linq *tutta la vita*. E' molto più probabile che produca tu a mano qualcosa di meno performante che non il runtime!

    HTH,
    tK

  5. #5
    Originariamente inviato da tekanet
    - per l'interrogazione di oggetti e collezioni, Linq *tutta la vita*. E' molto più probabile che produca tu a mano qualcosa di meno performante che non il runtime!
    quindi il runtime e' considerato rapido .. bene
    Quando avevo letto di questo Linq e delle var avevo pensato: "la solita Microsoft che reinventa la ruota e se ne vanta"
    poi ho pensato: ma che caspita me ne faccio di uno pseudo SQL su liste e collezioni?
    poi ho pensato: fammi provare sto Linq va ...
    ed in fine ho pensato: Linq *tutta la vita*

    mi ci son ritrovato bene fin da subito, il problema e' che i senior C# qui lamentano di:
    1 - non sapevano nemmeno che Linq potesse essere usato cosi' ... pensavano fosse solo il namespace XML ...
    2 - non acpiscono al volo il mio codice ...
    3 - mi hanno detto che e' impossibile da debuggare

    ecco, a parte i primi due punti che son fagiani, il terzo mi preoccupa ... effettivamente non ho capito se e' possibile monitorare quanto avviene in Linq durante i filtri where ... se non e' possibile valutare tutti i dati passanti a questo punto resto dell'idea che sia ottimo ma non perfetto ... penso comunque mi stia sbagliando ... consigli, guide, links?
    Grazie
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  6. #6
    Utente di HTML.it L'avatar di tekanet
    Registrato dal
    Oct 2001
    Messaggi
    299
    Sulle difficoltà di debug posso dare parzialmente ragione ai colleghi: quando viene modificata una query linq, occorre riavviare l'applicazione (non è supportato l'edit-and-continue).

    Per quanto riguarda i suggerimenti, questa serie di webcast è un'ottima rampa di lancio:
    http://msdn.microsoft.com/it-it/cc299390.aspx

    Come per tutte le tecnologie, dopo una "sfuriata" iniziale, IMHO è bene conoscerla e capire quando è opportuno utilizzarla e quando no. In certi casi ci si trova con enormi vantaggi rispetto ad un approcio basato su "for each" e "if". In altri potrebbe venire meno la leggibilità, senza avere un effettivo riscontro. In definitiva sta a te: non Linq per forza e ovunque, ma solo dove altrimenti la strada sarebbe più difficile che non con la sua adozione.

    Un piccolo-grande esempio. Problema: produci una lista di numeri interi da 1 a 100, in ordine casuale. Pensa a cosa dovresti mettere in piedi per risolverlo (nulla di impossibile, ma sicuramente non un problema da un minuto!). Poi guarda qui:
    http://msdn.microsoft.com/it-it/magazine/cc700332.aspx
    (e la seconda parte http://msdn.microsoft.com/it-it/magazine/cc793963.aspx )

    E' importante comunque farsi un'idea nitida di cos'è Linq, da cosa nasce e come lavora "sotto il cofano": sorprenderà capire che non è che la naturale evoluzione di un'insieme di tecnologie (tra le quali le lambda expressions, i tipi anonimi, la type inference), messe in sieme in maniera compatta e concreta.

  7. #7
    Per misurare le performance del codice è necessario creare dei test. Solo così puoi individuare colli di bottiglia e/o confrontare la differenza di utilizzare una query linq to xml oppure scriversi a manazza tutto il codice per tirare fuori un navigator a fronte di una query xpath.
    Per realizzare questi test puoi usare lo strumento integrato dentro visual studio (vs2008->menu analyze->Performance wizard.. session ecc) oppure di terze parti come ad es. dottrace http://www.jetbrains.com/profiler/

    Per quanto detto da tekanet, mi piacerebbe sapere dove e perchè si dice che linq to sql è al capolinea e che linq to entity abbia già la sua fine segnata.
    Saluti a tutti
    Riccardo

  8. #8
    Utente di HTML.it L'avatar di tekanet
    Registrato dal
    Oct 2001
    Messaggi
    299
    Originariamente inviato da riccardone
    Per quanto detto da tekanet, mi piacerebbe sapere dove e perchè si dice che linq to sql è al capolinea e che linq to entity abbia già la sua fine segnata.
    Ho detto che Linq to SQL è al capolinea già dall'inizio e che è l'Entity Framework la tecnologia da seguire per l'accesso ai dati con un OR/M Microsoft.

    E l'ho detto perché seguo il blog del team di Ado.NET:
    http://blogs.msdn.com/adonet/archive...s-roadmap.aspx

    Ai tempi quel post fece abbastanza parlare di sé in rete, tanto che il giorno dopo venne pubblicato un post chiarificatore:
    http://blogs.msdn.com/adonet/archive...s-futures.aspx

    Da quest'ultimo, estraggo:
    "Is LINQ to SQL Dead? We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios."

    In definitiva, come dicevo, per MS Linq2SQL è già sul viale del tramonto (purtroppo!) e Entity Framework è la tecnologia-bandiera per questo tipo di programmazione.

    Spero di aver risposto alla tua domanda

    tK

  9. #9

    Re: Linq ... il rovescio della medaglia?

    Originariamente inviato da andr3a
    Oggi ho usato Linq per la prima volta. Mi avevano detto di usare Linq per l'XML e dopo un paio di letture mi son messo giù a scrivere sql per interagire con liste di ogni tipo, come secondo parametro di foreach e altro ancora.

    Ora, quanto questo Linq incide sulle performances? Perchè tra lambda, runtime Anonymous assignment, clausole performate appunto in lambda ed altro ... mi son subito preoccupato delle performances.

    Allo stesso tempo un collega mi ha immediatamente detto: ok, su quegli if che avevo scritto io potevo mettere breakpoints e analizzare il tutto, su Linqu in query per filtrare come faccio a capire filtri e a debuggare?

    Io son certo ci siano metodi appositi per monitorare Linq ma non ho risposto, dato che conoscevo l'argomento più per sentito dire che altro ... ebbene, come sunto, mi dite quali sono i difetti di una classe, metodo, applicazione, scritte interamente in Linq? (o con uso massiccio, per intenderci)

    Grazie

    Io non mi preoccuperei eccessivamente. Giocaci con un profiler se vuoi sincerartene, ma a meno che tu non debba ripetere quell'istruzione 100000 volte sarà irrilevante.

    Parlando di performance in generale. Una volta mi è capitato di dover caricare cento file, scinderli ciascuno in un migliaio di stringhe (ad ogni newline) e confrontare ciascun file con ciascun altro file riassemblando le stringhe. Lì ho scoperto una IMMENSA differenza di performance tra string e StringBuilder. Ma quando la incontri la risolvi.

    Un mio collega mi faceva notare che un cast richiede circa 20 volte il tempo richiesto da un normale assegnamento. Tuttavia non tiene conto della velocità di un processore di oggi. Non tiene conto dei giorni uomo richiesti per correggere un codice meno strutturato, e soprattutto non tiene conto che un DAC strutturato male può trasformare i 0,1 secondi richiesti da una stored procedure in 2 secondi per una singola semplice get.

    I rallentamenti, nella mia esperienza, non sono dovuti ai milionesimi di secondo che si sommano, ma a castronate appunto da 0,5 secondi a botta. Però il profiler aiuta comunque.

    Anche i bug del framework contano. L'accesso a file XML di 300 MB in c# è performantissimo rispetto a Java, almeno usando DOM. Intendo secondi contro minuti.

    Oppure in MySQL le insert delayed sono velocissime rispetto alle insert (400.000). O ancora le subquery sono lente rispetto ai JOIN, ecc.

  10. #10
    Ho letto la discussione. L'80% degli interventi mi è sembrato spinto da un'ondata emotiva antimicrosoft. Per come la vedo io l'idea che due framework differenti che fanno le stesse cose ma in maniera diversa continuino a coesistere mi sembra poco intelligente ma tantè. Daltro canto chi usa linq to sql può continuare ad usarlo visto che nello stesso post che segnali si dice che verrà mantenuto e in più fa già farte del framework 3.5. Come tutte le cose che entrano nella versione ufficiale, anche linq to sql avrà un tempo di vita accettabile.
    Personalmente, visto che linq to sql è legato a sql server e che ha anche qualche limite in più nella rappresentazione del modello relazionale non vedo niente di male a spostarsi su LinQ to Entity.
    Non è poi vero che è più difficile. Diciamo che se lo vuoi usare su db differenti devi scaricarti e usare un provider differente e se vuoi rimappare questo a quello puoi farlo più a cuor leggero che non con linq to sql che invece e più legato allo schema del db sottostante.
    Per cui se devo fare qualcosa di veloce su sqlserver uso linq to sql, altrimenti quando sarà il momento (cioè quando farà parte di una release definitiva) userò linq to entity molto volentieri.
    Saluti a tutti
    Riccardo

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.