EViews 12 COM Automation

For notifying us of what you believe are bugs or errors in EViews.
Please ensure your copy of EViews is up-to-date before posting.

Moderators: EViews Gareth, EViews Moderator

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

EViews 12 COM Automation

Postby mmiller2 » Thu Oct 28, 2021 4:50 am

Were there any significant changes to the build configuration for the EViewsMgr.dll file that ships with EViews 12? We have a program that makes extensive use of COM to read and write from workfiles and the performance has degraded significantly after installling EViews12 and registering the COM components. Using the EViewsMgr.dll that shipped with EViews 11, the runtime is about 15 minutes. With the one from EViews 12, the runtime has suddenly increased to over 90 minutes.

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Thu Oct 28, 2021 8:19 am

The EViewsMgr.dll only houses the Manager object which doesn't do much work. The Application object itself resides in the main EViews executable.

It's possible that EViews 12 included some changes that may have slowed down some things, but it's hard to say without a concrete program example. We did write a forum post to help Troubleshoot EViews Slowness. Please refer to that for some possible fixes/workarounds.

If you can pinpoint a particular command that is much slower in EViews 12 than before, we can take a closer look at it. Use our TIC and TOC commands in your EViews program to help with timing particular sections.


Steve

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Fri Oct 29, 2021 5:47 am

Thanks for your suggestions Steve. Unfortunately, none of the fixes/workarounds on the troubleshooting page did the trick.

I'm working on developing a small demo program that pinpoints the issue, but we are very busy at this time of year and I might just be forced to revert to EViews 11 for the time being.

I'm not sure if I was unclear in the original post, but the issue only arises when running EViews commands thorugh the COM Interface. I haven't noticed a corresponding performance degradation when running programs directly in the EViews UI.

However, it's notable that we've been running these programs using the COM Interface since EViews 9, and this issue suddenly appeared with the release of EViews 12. If there weren't any obvious changes to the EViews source code that might have caused this, could there have been a change in calling convention or memory allocation that had unintended side effects for the COM interface?

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Fri Oct 29, 2021 7:36 am

I don't think there were any significant changes made to COM Automation interface for EViews 12, but your comments did make me think of something.

If you're not seeing the slowness when using the EViews 12 GUI directly, then it does seem to point to the actual COM interface itself, and EViews 12 is the first EViews version that is only available in 64-bit.

While COM Automation does work between a 32-bit client and a 64-bit host, it has to go thru a proxy layer to convert all data structures between 32-bit and 64-bit memory space, etc. If your calling application is a 32-bit process and you're transferring a large amount of data, then this proxy layer could be the reason why you're seeing such a slowdown. And since the proxy layer is handled by a Windows library, it is mostly out of our control.

Are you using a 32-bit calling application? Also, is your previous EViews 11 installation also 32-bit? If possible, please try using a 64-bit client process to see if that resolves your slowness issue.

For example, if your calling application is VBA macro code running inside Excel, switch to Excel 64-bit. Or if you're running VBA script (*.VBS) directly using wscript.exe, make sure you're using the wscript.exe located under C:\Windows\System32 instead of the one located under C:\Windows\SysWOW64\wscript.exe. Finally, if your client application is compiled using .NET, rebuild it by targeting 'x64' instead of 'x86' or 'Any'.

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Fri Oct 29, 2021 7:50 am

I've been doing everything in a 64-bit configuration - including building the external program that calls the COM interface - in both EViews 11 and EViews 12. I was wondering if EViews 12 might be delegating to the 32-bit proxy for some unknown reason whereas EViews 11 does not. In any event, something must have changed fundamentally.

Please unzip the attached archive to C:\Temp and double-click on eviewscom.exe to run the program. The program is a simple console application that runs the eviewsmgr.prg program through the COM interface as described in your 2015 whitepaper. After the program finishes, you can open the workfile C:\Temp\work.wf1 and examine the runtime stored in the scalar object named runtime.

When I did a regcomponents in EViews 11 and ran the program, the runtime was 58 s. The same procedure with EViews 12 increased the runtime to 821 s. That's a factor of 14 longer and consistent with what we've observed in other production programs. I saved my results in the workfiles work-11.wf1 and work-12.wf1, respectively.

Note that in addition to running regcomponents, you may also need to explicitly unregister a particular version of the COM interface by running regsvr32 /u EViewsMgr.dll in the C:\Program Files\EViews11\x86 or C:\Program Files\EViews12\x86 directories.
Attachments
work-12.wf1
(12.39 KiB) Downloaded 16 times
work-11.wf1
(12.39 KiB) Downloaded 17 times
EViewsCOM.zip
(26.39 KiB) Downloaded 20 times

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Fri Oct 29, 2021 9:43 am

Perfect, thanks for the program.

I believe the issue is caused by the fact that even if you run an EViews program via COM automation in an EViews application that is hidden, the program will still run with whatever your current program Run/Exec defaults are. Meaning if you have the program Verbose option turned on by default, then your program will be run that way, even over COM and even if you can't see the window.

This makes a significant difference in EViews 12 because we had to make some changes to some internal drawing functions that handle redrawing a window during a refresh. And because Verbose mode tries to refresh windows during program execution, this resulted in longer & longer redraw times as the number of objects increased in your loop.

The only reason you could run it this way in EViews 11 was because that version didn't properly refresh its windows during a program run.

So, long story short, you should always RUN or EXEC your programs (via COM) with the 'quiet' option if you don't care to view the application windows while it's running. I think we'll make this the default in our next version of EViews 13 (but only if the Application window is currently hidden), but for now, you should always run your programs over COM that way.

Like this:

Code: Select all

EXEC(quiet) c:\temp\eviewsmgr.prg

Or, if you'd rather control this in the program itself, you can add a line to your program at the beginning like this:

Code: Select all

tic
mode quiet
wfcreate(wf=c:\temp\work, page=a) a 1901 2100

In my tests, this program only took 0.82 seconds to complete when I turned on MODE QUIET and ran it with your program.

By the way, turning on QUIET mode was one of the suggestions in the Troubleshooting EViews Slowness posting... :)

Steve

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Fri Oct 29, 2021 11:12 am

Thanks for your help Steve! That fixed the original issue and gave us an unexpected performance boost. FYI, we have always run our programs in quiet mode in the EViews UI and didn't realize that the option set there didn't automatically apply to the COM environment. It seems that other options, like the current data path, do apply.

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Fri Oct 29, 2021 1:44 pm

Hmm, I thought you had verbose mode turned on via the GUI, so now I'm wondering why that setting didn't get shared when you ran it via COM. I don't think COM uses its own EViews32.ini settings file. Unless you were running your client program using a different user account than when you ran the GUI?

In any case, your COM clients should probably always insist on running any program in Quiet mode for best performance.

Also, I looked into the actual Verbose mode code itself and made some slight changes to make it A LOT more efficient when running in the GUI. These changes will be included in the next EViews 12 patch. With these changes, running your original program in VERBOSE mode now runs the loop section in around 3.2 seconds, and the final delete s* command in around 2.154 seconds.

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Wed Nov 03, 2021 8:26 am

I installed the 2021-11-02 patch today and there seems to be a performance degradation when running in quiet mode using COM. I had a production program running in 6 min yesterday which is now taking 23 min after installing the patch. Is there a way to rollback the patch so that I can rule out the patch itself as causing the issue?

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Wed Nov 03, 2021 9:33 am

Here's a link to previous patch: October 18, 2021 patch

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Wed Nov 03, 2021 10:16 am

Thanks Steve. I reinstalled the October patch and now the run time is back down to 5 minutes.

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Wed Nov 03, 2021 10:45 am

I've done some testing and I can't find anything in the latest patch that would've caused the slowdown.

Can you provide a program that shows this issue? I tried comparing your original program and even increased the amount of objects created to 100k but the latest version is faster (or the same) in my testing (in quiet mode).

mmiller2
Posts: 29
Joined: Tue Aug 23, 2016 9:56 am

Re: EViews 12 COM Automation

Postby mmiller2 » Fri Nov 05, 2021 4:47 am

Please unzip the attached archive to the C:\Temp directory and run the included program, patchtest.exe. It is a simple program that creates a workfile with 10,000 series objects in it and uses the COM function Application.GetSeries to load them. When running this program with the October patch, the runtime for me was about 7 seconds while it took about 140 seconds with the November patch. I have also attached my sample output for each case.

Based on a 20-fold increase in the runtime here just by switching the patch level, it would appear that you must have inadvertently coupled some additional overhead to the COM Application.GetSeries call with the November patch - even when running in quiet mode with an invisible window.

Are there any background threads that are running more frequently or additional background tasks with the new patch? The CPU activity while our production programs are running is noticeably higher with the new patch while the memory requirements are nearly identical.
Attachments
work-nov-10k.wf1
(12.39 KiB) Downloaded 12 times
work-oct-10k.wf1
(12.39 KiB) Downloaded 13 times
patchtest.zip
(27.4 KiB) Downloaded 14 times

EViews Steve
EViews Developer
Posts: 667
Joined: Tue Sep 16, 2008 3:00 pm
Location: Irvine, CA

Re: EViews 12 COM Automation

Postby EViews Steve » Fri Nov 05, 2021 8:00 am

Thanks. The issue has been resolved. This fix will be available in the next 12 patch.


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 5 guests