Performance Of SharePoint List Access Methods

As you might have experience throughout your SharePoint development, there are several methods available in SharePoint API to access the data from SharePoint lists. I wanted to measure the performance of each method available in SharePoint. In the following experiment, I have excluded SharePoint LINQ query. I’ll accommodate that with some other interesting metrics in my future post.

I have executed the following four different queries five time each on the same list in a particular sub-site. Number of executed time and the time taken to execute the query is depicted in the X axis and Y axis respectively.

Though I have played with all the available methods, certain situation may restrict you from using some of the optimized method. In case of if you are about to write an exe/console application, you can’t use PortalSiteMapProvider API.

Conculsion : Good Bye to SPQuery…!! Welcome to SPSiteDataQuery…!! Stay with me PortalSiteMapProvider…!!

P.S: The above data is extracted from Developer Dashboard, by enabling the SPMonitoredScope for each access mechanism.

SharePoint List Access Methods, SharePoint List Access Mechanism, SharePoint List Access, GetSiteData, SPSiteDataQuery

SPWeb Vs SPSite Vs SPWebApplication

If you are a beginner to SharePoint its vital to get an clear knowledge and should have a clear idea to distinguish SPWeb and SPSite and SPWebapplication. If you have a SharePoint environment setup in your machine try writing the following simple console application. This will go beyond the definitions and will be ease to understand and clarify these three buzz words.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Utilities;

namespace MyFirstTest
{
class Program
{
static void Main(string[] args)
{
SPSecurity.RunWithElevatedPrivileges(delegate()
{
SPWebApplicationCollection webappcol = SPWebService.ContentService.WebApplications;
foreach (SPWebApplication webapp in webappcol)
{
Console.WriteLine("Web Application URL :" + webapp.Name);

foreach (SPSite site in webapp.Sites)
{
Console.WriteLine("Site Collection URL :" + site.Url);
Console.ReadKey();

foreach (SPWeb web in site.AllWebs)
{
Console.WriteLine("Site URL :" + web.Url);
Console.ReadKey();
}
}
}

});
}
}
}

OutPut:

Web Application URL : Sharepoint-80

Site Collection URL : http://cd-Home

Site URL : http://cd-Home
http://cd-Home/Test
http://cd-Home/Test/Inside

Note:Since I am getting the "site.AllWebs" property it will iterate through all the webs in the Site Collection

Try in your environment you can understand the difference.....

Pagination for joint DVWP

As you might see, in sharepoint 2007 and in par with in sharepoint 2010 follow the same method on pagination for the joint list DVWP. If you add a single list, to DVWP and add pagination value, it normally works as expected. But once you link the existing datasource with another list, it automatically removes the pagination from the rendering part, still it keeps the xsl tags in the back-end. So how to enable the out of the box pagination.
Lets say "Category" List and "SubCategory" Lists are there. You are showing Sub Categories for the given Category. But all happens through the webpart. No addition of content type in page layout (Client requirement as they want to use the same layout for different purpose). If you link Category and SubCategory, pagination disappears. so you can't limit the number of SubCategories showing in webpart. In order to resolve that issue...
Obviously you can't enable the pagination by switching on and off, where as you have to write the xsl for the <xsl:template name="dvt_1.commandfooter"> template.
The parameters for the commandfooter template will be the same as default

<xsl:call-template name="dvt_1.commandfooter">
  <xsl:with-param name="FirstRow" select="$FirstRow" />
  <xsl:with-param name="LastRow" select="$LastRow" />
  <xsl:with-param name="RowLimit" select="$RowLimit" />
  <xsl:with-param name="dvt_RowCount" select="$dvt_RowCount" />
  <xsl:with-param name="RealLastRow" select="number(ddwrt:NameChanged('',-100))" />
</xsl:call-template>

and the template will be implemented like this

<xsl:template name="dvt_1.commandfooter">
<xsl:param name="FirstRow" />
<xsl:param name="LastRow" />
<xsl:param name="RowLimit" />
<xsl:param name="dvt_RowCount" />
<xsl:param name="RealLastRow" />
<xsl:variable name="preNumber" select="$FirstRow - $RowLimit" />
<xsl:variable name="nextNumber" select="$FirstRow + $RowLimit" />
<table><tbody><tr>
<xsl:if test="$FirstRow > 1">

</xsl:if><td>
<a href="/test1.aspx?PageLimit=$preNumber">Pre</a>
</td>

<xsl:if test="$nextNumber <= $dvt_RowCount">
</xsl:if><td>
<a href="/test1.aspx?PageLimit=$nextNumber">Next</a>
</td>
</tr>
</tbody></table>
</ xsl:template>

the parameter binding will be added with one more data as follows

<parameterbinding name="PageLimit" location="QueryString(PLimit)" defaultvalue="1" />

This is to limit the number of rows on the second list of joint view.
Assign the variables as follows

<xsl:variable name="FirstRow" select="$PageLimit" />
<xsl:variable name="LastRow" select="$FirstRow + $RowLimit" />

Call the body as follows

<xsl:call-template name="dvt_1.body">
  <xsl:with-param name="RowLimit" select="$RowLimit" />
  <xsl:with-param name="Rows" select="$Rows" />
  <xsl:with-param name="FirstRow" select="$FirstRow" />
  <xsl:with-param name="LastRow" select="$FirstRow + $RowLimit - 1" />
</xsl:call-template>

Now you are done with your pagination


P.S: This is my first blog post. Add your comments. :)