![]() |
If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Search this Thread | Display Modes |
|
#1
|
|||
|
|||
![]()
Hi,
I'm developing a C# based Outlook add-in using VSTO 2005. This add-in collects information from multiple Mail items, so I've a simple code like this: Outlook.MAPIFolder inbox = this.Application.ActiveExplorer().Session.GetDefau ltFolder(Outlook.OlDefaultFolders.olFolderInbox); Outlook.Items items = inbox.Items; foreach(Outlook.MailItem mailItem in items) { resultList.Add(new FoundMessageItem(mailItem)); //Takes some fields from the mailItem like subject, sender, recipient } Running this loop on even quite small mailbox (about 100 items) takes a long time (about 10-12 seconds) which is unexptable in my case. What can be done to improve the performance? Thanks in advance, Maxim |
#2
|
|||
|
|||
![]()
Interop code will always be slower than straight COM code, it's essentially
late bound and has all the overhead of the Interop and Framework. You can try using SetColumns to reduce the load time for each item in the Items collection (remember to clear that with ResetColumns when done) setting only the properties you need to work with. Other than that you'd need a faster API, such as CDO 1.21 or Extended MAPI, but neither is supported for .NET code. FWIW, if you ever run into non-mail items in Inbox your code will throw and exception and crash. You can have various other types of items there such as Posts, NDR's, meeting and task requests. Testing for the class of an item before casting it to a MailItem or enclosing the loop in a try...catch block would prevent the exception but then of course the code will be even slower. -- Ken Slovak [MVP - Outlook] http://www.slovaktech.com Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003 Reminder Manager, Extended Reminders, Attachment Options http://www.slovaktech.com/products.htm "maxim" wrote in message ... Hi, I'm developing a C# based Outlook add-in using VSTO 2005. This add-in collects information from multiple Mail items, so I've a simple code like this: Outlook.MAPIFolder inbox = this.Application.ActiveExplorer().Session.GetDefau ltFolder(Outlook.OlDefaultFolders.olFolderInbox); Outlook.Items items = inbox.Items; foreach(Outlook.MailItem mailItem in items) { resultList.Add(new FoundMessageItem(mailItem)); //Takes some fields from the mailItem like subject, sender, recipient } Running this loop on even quite small mailbox (about 100 items) takes a long time (about 10-12 seconds) which is unexptable in my case. What can be done to improve the performance? Thanks in advance, Maxim |
#3
|
|||
|
|||
![]()
Ken, thank you very much for your fast response.
I changed my code slightly to use CType paradigm of the VB.NET language, so my code now looks like: For Idx = 1 To items.Count item = items.GetNext() subject = CType(item.Subject, String) entryId = CType(item.EntryID, String) Next This loop works much faster than the C# analog. If I retrieve only Subject field, the performance is fantastic but it became much slower when I add additional fields like EntryId. Can you explain me pls, why there is so big difference between retrieving only Subject field and retrieving Subject and EntryId fields? Does Outlook performs requests to the Exchange server for retrieving fields other than Subject? I'm working with Outlook2003. Thanks, Maxim "Ken Slovak - [MVP - Outlook]" wrote: Interop code will always be slower than straight COM code, it's essentially late bound and has all the overhead of the Interop and Framework. You can try using SetColumns to reduce the load time for each item in the Items collection (remember to clear that with ResetColumns when done) setting only the properties you need to work with. Other than that you'd need a faster API, such as CDO 1.21 or Extended MAPI, but neither is supported for .NET code. FWIW, if you ever run into non-mail items in Inbox your code will throw and exception and crash. You can have various other types of items there such as Posts, NDR's, meeting and task requests. Testing for the class of an item before casting it to a MailItem or enclosing the loop in a try...catch block would prevent the exception but then of course the code will be even slower. -- Ken Slovak [MVP - Outlook] http://www.slovaktech.com Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003 Reminder Manager, Extended Reminders, Attachment Options http://www.slovaktech.com/products.htm "maxim" wrote in message ... Hi, I'm developing a C# based Outlook add-in using VSTO 2005. This add-in collects information from multiple Mail items, so I've a simple code like this: Outlook.MAPIFolder inbox = this.Application.ActiveExplorer().Session.GetDefau ltFolder(Outlook.OlDefaultFolders.olFolderInbox); Outlook.Items items = inbox.Items; foreach(Outlook.MailItem mailItem in items) { resultList.Add(new FoundMessageItem(mailItem)); //Takes some fields from the mailItem like subject, sender, recipient } Running this loop on even quite small mailbox (about 100 items) takes a long time (about 10-12 seconds) which is unexptable in my case. What can be done to improve the performance? Thanks in advance, Maxim |
#4
|
|||
|
|||
![]()
Retrieving 2 fields should be 1/2 as fast as retrieving 1 g
When you get an Item (in any way) Outlook loads all the properties for that item. There are special cases like cached mode download only headers and so on, but in general that's the behavior. If you use SetColumns to only load the properties you want things are much faster. Instead of loading everything the underlying MAPI is only loading those columns into each row of the Items table that you requested. That provides a large performance boost. Of course properties that are not in the SetColumns call are not available. I've never made any speed comparisons as to what type of loop is faster in various .NET languages. I do know that in VBA/VB6 for example that For...Each is faster than in indexed For loop. So different loop constructs can vary greatly in speed depending on their implementation. For all I know a do loop would be even faster (or it might be slower). Unless you can find the metrics for different types of loops you'd need to discover that for yourself. The C# groups might have answers for that sort of metrics. -- Ken Slovak [MVP - Outlook] http://www.slovaktech.com Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003 Reminder Manager, Extended Reminders, Attachment Options http://www.slovaktech.com/products.htm "maxim" wrote in message ... Ken, thank you very much for your fast response. I changed my code slightly to use CType paradigm of the VB.NET language, so my code now looks like: For Idx = 1 To items.Count item = items.GetNext() subject = CType(item.Subject, String) entryId = CType(item.EntryID, String) Next This loop works much faster than the C# analog. If I retrieve only Subject field, the performance is fantastic but it became much slower when I add additional fields like EntryId. Can you explain me pls, why there is so big difference between retrieving only Subject field and retrieving Subject and EntryId fields? Does Outlook performs requests to the Exchange server for retrieving fields other than Subject? I'm working with Outlook2003. Thanks, Maxim |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Performance problem by accessing the folder collections | Olivier Langlois | Outlook and VBA | 6 | November 2nd 06 07:20 AM |
Accessing custom fields in Outlook with VBA | netnews.comcast.net | Outlook and VBA | 0 | October 19th 06 06:50 PM |
VSTO Item events add and remove ... | lg | Add-ins for Outlook | 0 | October 12th 06 03:01 PM |
Outlook Contacts - Converting User-defined Item fields to Folder fields | [email protected] | Outlook - Using Contacts | 1 | September 29th 06 09:17 PM |
Outlook VSTO Appointment Item Delete Event | lg | Add-ins for Outlook | 0 | July 31st 06 10:35 AM |