Excel Performance

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

pearsons_11114 - 23 Nov 2005 01:10 GMT

I have a VB.NET app. calling to Excel using an interop assembly and am having
huge, unreasonable performance issues. To save a workbook takes 5 to 6 times
longer than under VB6. I've read up on the issues, but it's hard to believe
that _any_ issue related to threading or marshalling could be large relative
to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

Scott M. - 23 Nov 2005 01:26 GMT

When you use COM objects in a .NET application (or vice versa), wrapper
assemblies that contain wrapper classes are used to map the COM to .NET (or
vice versa) interfaces. Because of these extra layers, performance is
expected to suffer. To what degree it suffers varies, but with Excel, you
aren't just using one COM object, you are using several (application,
workbook, worksheet, cell, range, chart, etc.).

You must also remember to explicitly use: Marshal.ReleaseCOMObject for each
and every COM object you instantiate, otherwise Excel will continue to run
in the background.

>I have a VB.NET app. calling to Excel using an interop assembly and am
>having
[quoted text clipped - 5 lines]
> relative
> to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

pearsons_11114 - 23 Nov 2005 01:41 GMT

Hi, Scott.

Yep, I understand all of that. I've actually written a fairly complicated
application and am only now getting around to dealing with performance
issues. Nothing that happens in memory (threading, marshalling) should be on
the same order of magnitude as a disk write. When Excel writes a workbook,
there's no incremental write. It writes the whole thing, so it's very slow. I
can't see how anything I'm doing with interop wrappers is going to be that
slow, but it's taking 5 to 6 times longer. The only objects involved are
application, workbooks, and workbook. Just seems like something's
fundamentally wrong. It certainly makes .NET unusable for Office
applications, which I find very hard to believe.

> When you use COM objects in a .NET application (or vice versa), wrapper
> assemblies that contain wrapper classes are used to map the COM to .NET (or
[quoted text clipped - 16 lines]
> > relative
> > to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

Scott M. - 23 Nov 2005 04:20 GMT

You must be using Worksheets and Worksheet as well.

You also haven't told us much about the kind of app this is. Windows Forms?
Web Forms? Where is the file supposed to write to? Locally? Network?
When you say 5 to 6 times longer, that is longer than what? Are you
comparing apples to apples?

What about permissions to the directory where the write is happening?

> Hi, Scott.
>
[quoted text clipped - 35 lines]
>> > relative
>> > to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

pearsons_11114 - 23 Nov 2005 18:58 GMT

Ohhhhhhhhhhhhhhhh, you mean apples-to-apples. Duh. ;-)

When I changed the two tests to save the _same_ workbook, the times were
pretty close together. (The workbooks are way bigger in the new, .NET version
of the application. Somehow I managed to forget that).

Thanks and sorry for wasting your time. I have lots more interop questions,
but hopefully they'll be a little better thought out.

> You must be using Worksheets and Worksheet as well.
>
[quoted text clipped - 44 lines]
> >> > relative
> >> > to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

Jan - 29 Nov 2005 18:05 GMT

I would say it is expected behavior. If you need better performance, check
our ExcelLite (http://www.gemboxsoftware.com/ExcelLite.htm) or some other
third-party component.

Jan
GemBox Software

>I have a VB.NET app. calling to Excel using an interop assembly and am
>having
[quoted text clipped - 5 lines]
> relative
> to a disk write. Is this the expected behavior? Thanks.

Reply to this Message

Rate this thread:

Excel Performance

Free Magazines