Lazy Loading

Introduction

Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed. It can contribute to efficiency in the program’s operation if properly and appropriately used. The opposite of lazy loading is Eager Loading.

Article – 1: jQuery Tabs and Lazy Loading by Malcolm Sheridan

In this article I will connect to the Northwind database using LINQ to SQL, and display customer and product information in separate tabs. I’ll also show you one way of lazy loading these tabs so the data is retrieved only once, not each time a tab is selected.

Read more

Article – 2: Lazy Loading jQuery Tabs with ASP.NET by Mikesdotnetting

This article looks at efficient use of jQuery tabs when displaying data. Specifically, it covers how to lazy-load data, so that it is only accessed and displayed if the tab is clicked.

Lazy Loading is a well-known design pattern that is intended to prevent redundant processing within your application. In the case of tabbed data, there seems little point retrieving and binding data that appears in a tabbed area that no one looks at. So, this examples covers how to defer data access and display until the user wants it – which is defined by them clicking the relevant tab.

Read more

Article – 3: Eager Loading and Lazy Loading in ADO.NET Data Services by Gil Fink

The default behavior of a data service’s .NET client is not to load the entities’ associated objects. When we request an entity we will get it from the service but its associated objects will not load up at all.

Lets say that I have two entities in my program

• a course
• a department

The associations between the entities are that a department can have a lot of courses and a course belongs to one department.

When I load a department it’s list of courses will be empty. trying to iterate the list of courses will give nothing because the courses will not load until we tell them to be loaded explicitly.

This is done by the LoadProperty method of the data service context.

Read more

 

I have a great learning experience thru this.

Now its your turn to have it.

.NET Challenge – for or foreach?

Question:

for should be used instead of foreach to iterate over collections in performance-critical loops.

Answer: True

foreach uses an enumerator which can sometimes be slower than the simple iteration of a variable in a for loop. Enumerators, such as those contained in the .NET Framework, have both managed heap and virtual function overhead. The amount of overhead depends on the collection used and the version of the .NET Framework. As always, the best way to determine the overhead between techniques is to run a performance test and compare.

To illustrate the performance impact, 10 strings were concatenated 100 times using the techniques outlined below. 

Running against .NET Framework 3.5 using an ArrayList, a generic List and a LinkedList with 5,000 strings, the following results were obtained using Ants Performance Profiler 5:

Wall Clock Time (ms)	Loop	Structure (5,000 strings)
25.003	for	LinkedList<string>
0.037	foreach	LinkedList<string>
0.039	for	ArrayList
0.053	foreach	ArrayList
0.019	for	List<string>
0.034	foreach	List<string>

 

Except for the LinkedList, the for loop is faster.

The for loop is thought by many developers to be less readable and maintainable than foreach. Using foreach also makes it possible to iterate across anything that’s IEnumerable, allowing for the creation of more general algorithms and the use of "yield" to build custom collections.

It is normally good practice to code for clarity rather than micro-optimization.

Reference : Rad-gate

Watch the Video of Luke Hoban & Luca Bolognese

Linq to SQL by Luca Bolognese

Luca Bolognese is the Principal Program Manager Lead on the C# team. His talk on LINQ to SQL endows developers with the knowledge necessary to wield the tools that drive data driven application development under C# 3.0. A consummate speaker, Luca skillfully guides his audience through the elements that comprise LINQ to SQL development.

watch the video here

An In-Depth Look at C# 3.0 by Luke Hoban

Luke Hoban was the PM who drove the development of LINQ to Objects, and the man who created the now famous implementation of a ray tracer in a single, very long, LINQ query expression. He is now focusing his efforts on F#. By listening to his talk on C# 3.0 features you will get a chance to see a detailed and specific analysis of how LINQ works. Listening to him give this talk marked a turning point in my understanding of LINQ. For the first time I understood how the team folded extension methods and query expressions together to create the marvelously supple and deceptively simple syntax that we know as LINQ.

watch the video here