This project has moved and is read-only. For the latest updates, please go here.

DocVariables access slow

May 15, 2014 at 8:38 AM

great tool, but if i call
or update a Variable via
var varToWrite = variables.FirstOrDefault(variable => variable.Name == name);
varToWrite.Value = value;
the access is very slow (office 2013).

What can I do?

May 16, 2014 at 10:01 PM
what means very slow in fact? (milliseconds, seconds or minutes?)

i want reproduce your scenario but need to know the count (and may content) of your variables and your office document format(.xlsx?) and its a new document or existing document.

(my current idea is is: the application use some harddrive operations to validate the variables and this ops decrease the performance)

May 17, 2014 at 7:17 AM
Here some facts:
  • the performance ist reduced by factor 30 (about)
  • The count of variables is about 70, strings with length of 10-50
  • The document ist new generated Word-Document via a template (loading DOCX)
  • this problem occours at an customer sytem, at my test system, all ist fine
  • My previous method controls addin/opdating variables by OLE-Automation (Visual Foxpro). In this case, there ist a small performance impact only at the customer system (about factor 2),
  • The customer uses Office 2010 (not 2013), my Test System uses Office 2003.
  • The Customer uses Office in as Terminal Services Environment (Windows 2003)
  • I try to take some measures in end of the next week.
What do you mean with "harddrive operations to validate"? Word hosts the Variables in memory.

If this is too specifically for this forum, you can mail me:

May 20, 2014 at 10:00 AM
hey man,

i didnt understand your prev solution. ( i need this to compare & analyze the problem) sounds like VBA for me. (BTW: FoxPro is still alive? never heard of them since 2000....)

what i mean with hd operations is: word is a bit special in deal with meta data. this means, word check for the doc/docx file in any case here for all meta data operations( you can see/observe this with a a special SysInternals tool(by the great Mark Russinovic).
thats the reason why i ask for its new or existing file.(i see, its new and UNSAVED(true???), no need for hd operations)

What can i say currently is:

may bad news: accessing a COM application from .NET is MUCH slower as VBA or VB6/5. ( a lot of .NET infrastructure code is necessary to break the wall from managed to unmanaged) regardless from any API(VSTO, NetOffice, Interop) you want you use.
you may face this kind of performance problem. the only way to fix this is, reduce the count of calls to office as much you can. in other words: the call to office himself is the reason for the performance decrease.

Summary: This is a performance problem(very special, normaly is gimme some code snippets and i told you whats happen).
This situation is different. Anyway, i want reproduce the scenario now, (A)VBA in Word, (B)NetOffice in .exe. if its done, i want come back.