Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

di il
6 risposte

Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

Ciao a tutti , 

volevo avere un idea indicativa di quanto PLinq migliora le le performance rispetto al classico linq , 

per fare questo ho aggiunto 2 milioni di record alla tabella Products del database di esempio Northwind per sql server ,

quello che segue è il codice utilizzato

public async Task<IActionResult> Test()
{
    //var northwindContext = _context.Products.Include(p => p.Category).Include(p => p.Supplier);
    DateTime dt1 = DateTime.Now;
    var list = from p in _context.Products.AsParallel() where p.ProductName.Contains("%0%") select p;
    //var list = from p in _context.Products where p.ProductName.Contains("%0%") select p;
    DateTime dt2 = DateTime.Now;
    TimeSpan span = dt2.Subtract(dt1);
    ViewData["Milliseconds"] = span.TotalMilliseconds;
    return View("Test");
}

eseguendo senza debug
ho stampato il valore di span.TotalMilliseconds nella view Test

milliseconds senza parallel 500,7341 ; 596,1122; 593,8073;
milliseconds con parallel   0,6659 0,0194 0,6461; 0,0204

tra un esecuzione e l'altra ho pulito e ricompilato il progetto ma i risultati mi sembra che non siano significativi in quanto troppo distanti ,come si potrebbe fare qualche test più significativo per quantificare “spannometricamente” la differenza di performance tra le due librerie?

grazie,

ciao

6 Risposte

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    Non puoi usare l'accesso a sql server per fare queste valutazioni così come se niente fosse. 

    sql server, come qualunque dbms serio, fa un sacco di cose ‘strane’ : cache della query, cache del risultato, svuotamento della cache, creazione e (finta) chiusura della connessione, reale chiusura della connessione, ecc. 

    tutto questo per migliorare l'efficienza dell'accesso ai dati MA basandosi su un ‘pattern standard’ di utilizzo. 

    il pallelismo supportato da sql server NON SERVE per aumentare la quantità di dati trasferita, MA per gestire il maggior numero di client/utenti/connessioni possibile. 

    Quando trasferisci dati dalla tabella in memoria lo fai già alla massima velocità di trasferimento supportata dall'hatdware. Molto probabilmente stai usando il DMA (direct memory access). 


    il miglioramento OTTIMO, usando N threads su un'applicazione che e' PERFETTAMENTE parallelizabile, e'  avere i tempi di calcolo pari ad 1/N, 

    MA 

    “N” non puo' essere piu' grande al numero di thread REALI. 
    L' hypertreading è un modo ARTIFICIALE di aumentare il numero di thread hardware: sono piu' thread nello stesso core fisico, il che vuol dire che su quel core ci puo' girare COMUNQUE UN SOLO thread alla volta (anche se lo switch di contesto tra un thread e l'altro e' molto piu' efficiente dell'implementazione “classica” basata sul sistema operativo).

    Ovviamente sara' SEMPRE di meno. Se sei fortunato e se le cose sono fatte mooolto bene, di poco.

    Ma questo e' solo UNO dei tanti possibili approcci al multithreading.

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    Grazie della risposta , un metodo per ottenere dei dati comparativi tra linq e Plinq quindi forse non esiste?

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    Linq e PLinq sono sue “framework” per scandire “collezioni” (che possono essere collezioni .NET OPPURE tabelle di database) in modo “sequenziale” e “parallelo” usando una sintassi “SQL-like” integrata DIRETTAMENTE in C# 
    (che OBBROBRIO/ORRORE, Bleak!). 
    NON SONO framework per accedere SOLO ad un DBMS.

    Nel caso piu' semplice, devi usare collezioni “in memoria”/normali collezioni .NET.

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    08/09/2024 - gian82 ha scritto:


    volevo avere un idea indicativa di quanto PLinq migliora le le performance rispetto al classico linq […]

    Non ha senso valutare delle performance senza qualcosa da “far fare” alla libreria. Il contesto del multithreading ha un suo costo, quindi va usato dove c'è un effettivo bisogno di quell'approccio e laddove esso costituisce un vantaggio, non solo in termini di performance pure.

    Non è che PLINQ è la “versione migliorata” e più veloce di LINQ: è parallela, appunto, ma il “parallelismo” deve essere utilizzato per uno scopo.

    Se lo usi per misurare prestazioni che includono un accesso ai dati in quel modo, e quindi coinvolgono un I/O, non stai neanche misurando le prestazioni della libreria: che senso ha guardare quanto la libreria “parallela” è più veloce di quella “tradizionale” nell'atto di dover “attendere” le operazioni di I/O da uno storage (il DB)? Le prestazioni sono equivalenti perché in entrambi i casi, anche se molto rapido, entrambe sono in attesa del “collo di bottiglia” maggiore, che è il DB.

    In definitiva, devi contestualizzare lo scenario e trovarti in un contesto in cui abbia senso “parallelizzare”.

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    "Le prestazioni sono equivalenti " , a me sembra che siano troppo distanti ,senza parallel mezzo secondo ,con parallel poco più di mezzo millesimo di secondo … 

  • Re: Quanto migliora la velocità di esecuzione l'uso di ParallelLinq ?

    09/09/2024 - gian82 ha scritto:


    "Le prestazioni sono equivalenti " , a me sembra che siano troppo distanti ,senza parallel mezzo secondo ,con parallel poco più di mezzo millesimo di secondo … 

    Vale quanto detto da migliorabile:

    09/09/2024 - migliorabile ha scritto:


    sql server, come qualunque dbms serio, fa un sacco di cose ‘strane’ : cache della query, cache del risultato, svuotamento della cache, creazione e (finta) chiusura della connessione, reale chiusura della connessione, ecc. 

    Tra l'altro, anche Entity Framework (che mi pare sia la libreria utilizzata) “ci mette del suo”.

    Non è detto che il risultato sia ripetibile, o che sia lo stesso con ordine invertito delle operazioni, senza tralasciare il fatto che .NET non è un ambiente deterministico (es. il Garbage Collector potrebbe intervenire e/o interferire in qualsiasi momento, fuori dal controllo dello sviluppatore).

    In breve, è il test a non essere valido.

Devi accedere o registrarti per scrivere nel forum
6 risposte