Is LINQ banned in your company?

Question

I work for a large company who develop enterprise applications which are performance oriented. Virtually every line of code is closely scrutinised and optimized as much as possible to ensure the best performance.

Company policy dictates that LINQ is strictly banned. This is because it is believed that LINQ has a negative performance impact compared to more traditional coding practices.

Is LINQ banned in your company? If yes, what are the reason given for this? If not, what applications does your company develop and why is performance not so crucial?

Answer 1

LINQ is not banned. Low quality O/R mappers (LINQ2SQL, Entity Framework) are. We use alterantives - NHibernate when a full ORM is needed, BLToolkit for fast mapping to SQL. Main application is very real time sensitive, but LINQ (language extension) has a lot to offer, and the impact is neglegible if well used (reviews).

To add to that - I am now mostly in the financial area. Due to the nature of the application, elemets like "change tracking" are not needed. There ARE NO CHANGES.

Every entity written to the db or pulled from it is immutable. Changes are done by submitting change requests to a service, which will do the calculations and write a new line to the database. There are "Entities" that contain the key of the item and the last known data value as single property (as published - pulled from the db), but it is, as I said, immutable.

Performacne is crucial because the mechanism is event driven and has to cale to a million events - per second. THis is why we go for the db operations now there with something "thin" like BLToolkit - we dont need any of the higher up funcitons.

Answer 2

why is performance not so crucial

Performance is often important - but that doesn't mean that every line has to be optimized to the hilt. Heck, often whole components are far from the critical path.

Often it's more important to get the overall architecture/design right - that's where big savings can usually be made. It's easier to spend time on the higher level design if you know you'll then be able to implement it in a readable, maintainable way... and LINQ can help you to achieve exactly that sort of implementation.

Answer 3

At the company where I work the rules are quite simple:

1. Everything not approved is forbidden.
2. Everthing which is approved is mandatory.

LINQ, of course, is not approved.

Power to the proletariat. :\

Answer 4

We certainly don't ban LINQ, I use it a lot, but in perf hot spots we have in one case I know of gone back and reworked LINQ code to non-LINQ. Performance is extremely important in the applications I develop.

Banning a technology as powerful and as useful as LINQ is very short sighted and is not the way to improve performance. If you want to imporve performance then invest in a good profiler and take the time to use it.

Answer 5

I, personally, do not ban LINQ usage in my company - but rather encourage its use whenever appropriate. LINQ is very expressive, and I find that it produces code that is often much more maintainable, and higher quality, than "traditional" methods of development.

In addition, I often find that many developers tend to write more performant code using LINQ than "traditional" looping methods. The streaming nature of LINQ can dramatically cut down on the runtimes if used correctly.

Personally, I find that any company that "bans" the usage of a specific language or framework feature outright has higher level problems. Every technology exists for a reason - and every feature has its place. Whether it's appropriate in a specific scenario is another issue - but banning it completely is a sign of poor management of developers, in my opinion.

If not, what applications does your company develop and why is performance not so crucial?

Performance is absolutely critical to me. My company develops scientific software, and many of our routines have runtimes in the hours (or even days), so every ounce of performance we can squeeze out is very useful.

That being said, performance doesn't come from micro-optimizing in most cases - it comes from designing a better architecture and "large scale" algorithms. The key for this to be truly successful is having a good design, and keeping the code as simple as possible. Simplicity helps in profiling tremendously - which in turn can pin point the real performance issues in the application.

Occasionally this will be due to a LINQ statement, but very rarely. More often this is due to a poor design decision. I find that LINQ actually reduces the frequency of poor design decisions. It's much easier to refactor a LINQ statement into a more performant tight loop when necessary than it is to try to profile an application that's "chattier" in terms of code than necessary.

In addition, LINQ has some huge performance opportunities, even on a small scale. For example, it's much simpler to parallelize a LINQ query via PLINQ than to try to parallelize many other constructs, for example. Granted, it's not magic, and care still needs to be taken, but LINQ tends to parallelize with fewer issues than loops. If performance is the goal, simple, clean code should be the target, and LINQ helps achieve that more quickly.

Answer 6

Company policy dictates that LINQ is strictly banned. This is because it is believed that LINQ has a negative performance impact compared to more traditional coding practices

We don't ban LINQ simply because we don't share those beliefs. Instead, we profiled some representative samples using LINQ and using more "traditional" coding practices and found that the performance of LINQ was in line with the performance of our hand-written loops.

In the work we do, getting something working is paramount. We've found that LINQ lets us write working code more quickly, more clearly, and in fewer lines. In the very few cases where a LINQ expression appears to be a performance problem, we've found that the problem isn't with LINQ but rather with our overall algorithm. Hand coding an alternative to the LINQ expression almost never results in a significant performance boost.

Your last question is "why is performance not so critical?" Believe me, performance is critical in what we do, and we've found that using LINQ does not negatively impact performance.

I would suggest that you question the reasons behind the LINQ ban, and perhaps do some profiling of your own. You might be very surprised at the results.

Answer 7

I thankfully work for a company that isn't afraid to let their developers think. An outright ban seems rather short sighted.

Answer 8

When you start using LINQ, It's gonna be hard for you to switch back to traditional one. I guess there are bunch of doubts that keeps the company away of using LINQ. Cause there Is a little bit chance that Microsoft will remove LINQ in the feature, and they not gonna support anymore. and the other one Is your upper level managers don't know about the LINQ and new features and they don't wanna investigate more. They just say don't use that.

Answer 9

I ran across a hand-coded for loop in our system a couple of months ago, which was commented to indicate that it was done this way because it would be faster than using LINQ. At the time, this developer didn't fully understand the inner workings of LINQ, and made the erroneous assumption that performing multiple operations in a single loop would be more performant than chaining LINQ operations.

I suspected that this wouldn't actually save us much time, if any, so I wrote a quick benchmark which found that a one-line LINQ statement actually evaluated faster than the loop. I showed it to the developer (who has no ego, and immediately saw the error in his ways), and we all moved on as better people.

There are times where LINQ can be misused in such a way as to be costly, performance-wise. But most of these mistakes can be caught with a code review (which it sounds like you already do religiously), combined with maybe a few brown-bag lunches to discuss pitfalls to avoid.

One other thing I'd point out is that I was able to get a 3x performance boost from some of our longer-running unit tests simply by adding .AsParallel() to the beginning of a LINQ query and changing a foreach statement to items.ForAll(...). PLINQ makes it really easy to get a big performance boost where you probably wouldn't otherwise have had time to make a multi-threading optimization.

Answer 10

Virtually every line of code is closely scrutinised and optimized as much as possible to ensure the best performance.

Scrutinize and optimize this quoted line, and realize that greedy optimization can't achieve the gains that a creative thinker can.

There are mainstream professional programmers (who do write data acess code) out there that do not comprehend what an index is, what a query optimizer does or what a good query plan looks like. These programmers do have to optimize every "line" because their data access runs 1000s of times longer than it should.

Is LINQ banned in your company?

No.

If not, what applications does your company develop and why is performance not so crucial?

I use LinqToSql to write more performant data access than I could write by stored proc or by raw ADO.NET.

• Programmer brain bandwidth matters.
• Minimizing redundant access across many operations matters.
• Profiling tools matter.

Answer 11

Granted LinqToSql has some memory overhead with the DataContext. But it does give you the power to override any table operation (even select) with a nicely tuned stored procedure. This gives you the best of both worlds by letting you tune where it matters. LinqToSql is quite powerful and much higher quality than some others on this thread would have you believe.

When you calculate the cost of doing it the old way compared with the new way it should not be too difficult to sell.

Answer 12

Performance-optimized and C# don't belong in the same sentence.