1

May be this is a silly programming question.

am performing a CAML QUERY which fetches some 500+ records, a projectcode column from a splist and am inserting into a list<string> object. This is performed inside a timer job, within the Execute() .

Now I need to traverse to a document library with this projectcode column and need fetch those records that matches same projectcode. Both these list and doc lib are in the same site collection.

Wanted to know which feature of C# will i use ? I am having array, list<> , hashtable or something new. Which one is more performant ?

Some CAML QUERY that fetches the projectcode from the splistitecollection object

list<String> objProjCodes = new List<string>();

and in the foraech loop, am adding the

if (currlistem["projeccode"] != null)
{
 objProjCodes.add(currlistitem["projectcode"].tostring());
}

Is there any way, I can perform this operation in a more high performant way? other than list<> or array, any other new collection class, can be used here? so that,performance will b li'l bit better!

Now I need to traverse to a document library that's having same projectcode and fetch all those listitemcolletion , again by using different CAML query. After this, I need to perform permission management on these selected items in the document library.

Cant use the itemevent receiver since I am having a comparison with datecolumn with todaysdate and this sourcelist is not getting updated by manually. Its a scheduled job.

Kind of OLTP system, having primary key and foriegn key concepts. :-(

2

Any performance issues you're having are more likely to be due to how you're accessing the sharepoint lists, rather than the costs of a hashtable vs generic list. Looping through all items in a library is going to be an inherently slow process (compared to accessing the same number of rows in a sql database). But check out request batching. Also, perhaps check into the possibility of doing joins (just scroll down a bit on that page).

Another possibility (which perhaps is what you're already doing) would be to load all the data up-front, do the joins in memory, and then send batch updates back as needed, instead of repeatedly querying the list for matching records.

Other standard performance advice applies: make sure you're returning only the fields you need, instead of all fields in the list.

Of course, with timer jobs, the standard warning applies: MS is moving away from the server-side code model, and at some point you may want to consider a powershell script that uses the client side object model instead of chewing up server memory for this operation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.