I recently started using Lazy throughout my application, and I was wondering if there are any obvious negative aspects that I need to take into account when using Lazy<T>?
I am trying to utilize Lazy<T> as often as I deem it appropriate, primarily to help reduce the memory footprint of our loaded, but inactive plugins.
I'll expand a bit on my comment, which reads:
I've just started using Lazy, and find that it's often indicative of bad design; or laziness on the part of the programmer. Also, one disadvantage is that you have to be more vigilant with scoped up variables, and create proper closures.
For example, I've used Lazy<T> to create the pages the user can see in my (sessionless) MVC app. It's a guiding wizard, so the user might want to go to a random previous step. When the handshake is made, an array of Lazy<Page> objects is crated, and if the user specifies as step, that exact page is evaluated. I find it delivers good performance, but there are some aspects to it that I don't like, for example many of my foreach constructs now look like this:
foreach(var something in somethings){
var somethingClosure = something;
list.Add(new Lazy<Page>(() => new Page(somethingClosure));
}
I.e. you have to deal with the problem of closures very proactively. Otherwise I don't think it's such a bad performance hit to store a lambda and evaluate it when needed.
On the other hand this might be indicative that the programmer is being a Lazy<Programmer>, in the sense that you'd prefer not thinking through your program now, and instead let the proper logic evaluate when needed, as with example in my case - instead of building that array, I could just figure out just what that specific requested page would be; but I chose to be lazy, and do an all in approach.
EDIT
It occurs to me that Lazy<T> also has a few peculiars when working with concurrency. For example there's a ThreadLocal<T> for some scenarios, and several flag configurations for your particular multi-threaded scenario. You can read more on msdn.
Lazy<T> per se. Rather, it's how you use it. –
Exponible var somethingClosure = something; I've been looking for something to call my closures... Oh I'm kicking myself. –
Homothermal In my opinion, you should always have a reason for choosing Lazy. There are several alternatives depending on the use case and there are definitely cases where this structure is appropriate. But don't use it just because it's cool.
For example I don't get the point in the page selection example in one of the other answers. Using a list of Lazy for selecting a single element can be well done with a list or dictionary of delegates directly without using Lazy or with a simple switch statement.
So the most obvious alternatives are
In contrast to that, Lazy is often suitable when
Here's not quite a negative aspect, but a gotcha for lazy people :).
Lazy initializers are like static initializers. They get run once. If an exception is thrown, the exception is cached and subsequent calls to .Value would throw the same exception. This is by design and is mentioned in the docs ... http://msdn.microsoft.com/en-us/library/dd642329.aspx:
Exceptions that are thrown by valueFactory are cached.
Hence, code as below will never return a value:
bool firstTime = true;
Lazy<int> lazyInt = new Lazy<int>(() =>
{
if (firstTime)
{
firstTime = false;
throw new Exception("Always throws exception the very first time.");
}
return 21;
});
int? val = null;
while (val == null)
{
try
{
val = lazyInt.Value;
}
catch
{
}
}
LazyWithNoExceptionCaching if you want to avoid exception caching - https://mcmap.net/q/67008/-system-lazy-lt-t-gt-with-different-thread-safety-mode-duplicate –
Reparable I've come to use Lazy<T> mainly because of it's concurrency capabilities while loading resources from database. Thus I got rid of lock objects and arguable locking patterns.
In my case ConcurrentDictionary + Lazy as a value made my day, thanks to @Reed Copsey and his blog post
This looks like the following. Instead of calling:
MyValue value = dictionary.GetOrAdd( key, () => new MyValue(key));We would instead use a ConcurrentDictionary<TKey, Lazy>, and write:
MyValue value = dictionary.GetOrAdd( key, () => new Lazy<MyValue>( () => new MyValue(key))) .Value;
No downsides of Lazy<T> noticed so far.
As with anything, Lazy<T> can be used for good or for evil, hence a disadvantage: when used inappropriately, it can cause confusion and frustration. However, lazy initialization pattern has been around for years, and now that .NET BCL has an implementation developers don't need to reinvent the wheel yet again. What's more, MEF loves Lazy.
What exactly do you mean with "throughout my application"?
I think it should only be used when you're not sure if the value will be used or not, which may only be the case with optional parameters that take a long time to compute. This could include complex calculations, file-handling, Webservices, database access and so on.
On the other hand, why use Lazy here? In most cases you can simply call a method instead of lazy.Value and it makes no difference anyway. BUT it's more simple and obvious to the programmer what's happening in this situation without Lazy.
One obvious upside may be already implemented caching of the value, but I don't think this is such a big advantage.
Lazy is used to preserve resources while not really needed. This pattern is pretty good but implementation can be useless.
Bigger the resource is, usefull is this pattern.
A disavantage to use Lazy class is the non transparency of usage. Indeed, you have to maintain everywhere an additional indirection (.Value). When you just need an instance of real type, it is forced to load even if you dont need to use it directly.
Lazy is for lazy developpement gaining productivity but this gain can be lost by high usage.
If you have a real transparent implementation (using proxy pattern for exemple) it get rid of disavantage and it can be very usefull in many case.
Concurrency must be consider in an other aspect and not implemented by default in your type. It must be included only in client code or type helpers for this concept.
© 2022 - 2024 — McMap. All rights reserved.