A stored procedure or a query generated by LLBLGen Pro are threated the same by the database: the SQL is interpreted and transformed into an execution plan, which is executed. The execution plan is cached. WHen the query is executed again on the client, the same execution plan is executed.
So there's no performance advantage for procs there.
What you should do is looking into ways to do as much as possible on the database when you're dealing with big sets of data: it's not efficient to read millions of rows to the client, process them there and send them back: it's then easier to process them on the database side. LLBLGen Pro allows you to write very complex queries so it's very often perfectly possible to use llblgen pro generated queries for this purpose. If you still need a big stored procedure to process data, you can, even for fetching entities (through projections)
So you're flexible in this: if you really need to go for a procedure because the query is very long and needs things like temptables, cursors etc. so you need a big procedure, you can offload that logic to a procedure and use that in your project. So it's flexible, it's up to you what to use where, you're not forced to use one over the other.
(prefetch paths and insert/update/delete queries are done with dynamic sql generated by llblgen pro. However this isn't a problem, most bottlenecks are in fetches, e.g. reports aggregating millions of rows)
