PLINQ slower than actual Linq for this snippet

Question

Below is the code snippet. EF6 is used.

var itemNames = context.cam.AsParallel()
                    .Where(x=> x.cams == 
                     "edsfdf")
                    .Select(item => item.fg)
                    .FirstOrDefault();

Why is PLINQ slower?

this looks, more like a news than a question. what is your question? — Ashkan Mobayen Khiabani, Sep 28 '18 at 21:15
Doing things on multiple threads is not always faster than running them single threaded. There are a lot of factors to be considered before you start to use parallel instructions in your code. — meJustAndrew, Sep 28 '18 at 21:17
If the table cam is very large, you may consider a parallell approach. Then you could use individual DbContext or ObjectContext instances and use a CancellationTokenSource, so you could cancel the parallell search as soon as you find the matching row and return as soon as possible. — Tore Aurstad, Sep 28 '18 at 21:28
[This answer](https://stackoverflow.com/a/29754749) might be relevant: *Note that LINQ-To-Entities doesn't really work with `AsParallel`. Usually, it will cause your code to run slower then it will sequentially.* — dbc, Sep 28 '18 at 21:30
`.AsParallel()` takes an IEnumerable, not an IQueryable, so if this is Linq-To-Entities, it's not just running slower, it's enumerating the whole table into memory (no where clause before the AsParallel) and then running the Where and Select enumerators in memory. — Eric Damtoft, Sep 28 '18 at 22:15

Eric Damtoft · Accepted Answer · 2018-09-30T18:51:09.117

If you look at the signature of .AsParallel(), it takes an IEnumerable<T>, rather than an IQueryable<T>. A linq query is only converted to a SQL statement while it's kept as an IQueryable. Once you enumerate it, it executes the query and returns the records.

So to break down the query you have:

context.cam.AsParallel()

This bit of code essentially will execute SELECT * FROM cam on the database, and then start iterating through the results.The results will be passed into a ParallelQuery. This essentially will load the entire table into memory.

.Where(x=> x.cams == "edsfdf")
.Select(item => item.fg)
.FirstOrDefault()

After this point, all of those operations will happen in parallel. A simple string equality comparison is likely extremely inexpensive compared to the overhead of spinning up a lot of threads and managing locking and concurrency between them (which PLINQ will take care of for you). Parallel processing and the costs/benefits is a complicated topic, but it's usually best saved for CPU-intensive work.

If you skipped the AsParallel() call, everything remains as an IQueryable all the way through the linq statement, so EntityFramework will send a single SQL command that looks something like SELECT fg FROM cam WHERE cams = 'edsfdf' and return that single result, which SQL Server will optimize to a very fast lookup, especially if there's an index on cams.

The explanation is pretty clear. If PLINQ comes with associated complexity then what is the real benefit for it's existence? — ash, Sep 28 '18 at 23:31
Also, It would be helpful If you can share case studies that details its ideal usage. Thanks! — ash, Sep 28 '18 at 23:32
https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/understanding-speedup-in-plinq has some good info on when PLINQ is most useful. — Eric Damtoft, Sep 28 '18 at 23:42

Ayub · Answer 2 · 2020-09-17T13:35:38.630

It's slower because you have used parralisim in a bad place. Your Where clause doesn't do heavy duty work, then it's not good scenario to use PLINQ.

If PLINQ comes with associated complexity then what is the real benefit for it's existence?

You don't need hundred people to find a missing child in a home, because finding 100 people takes longer than finding the child by yourself. But if you were to search a forest, this overhead was worth it, because finding a child in a big forest alone takes longer than to find 100 people to find a child in a big forest!

parallelism is effective when used at the right time in the right place.

PLINQ slower than actual Linq for this snippet

2 Answers2