0

I have a VB6 application that uses FileNet Visual Workflo (on FileNet Image Services) for the workflow engine. All of our application code has been updated to work correctly on both Windows XP and Windows 7, but there is a performance problem on Win 7 when attempting to get work object information from FileNet.

Within the application are calls such as

  ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)

to which I've isolated the performance issue.

APIVWAPI is defined via late binding as follows:

 Set APIVWAPI = CreateObject("VWApi.Srv")

The 

 ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)

line takes approximately 40 times longer on the Windows 7 machine (Core i7 3.4GHz CPU 8GB RAM) as it does on a Windows XP machine (Pentinum 4 3.2GHz, 1GB RAM). This line (and those like it) is called multiple times when retrieving queue items. As an example, a 120 item queue will take about 40 seconds to load on Windows 7 and <1 second on Windows XP.

Both systems are using the latest FileNet IDM components (4.0.3 fix pack 1). The Windows 7 environment is 64-bit Enterprise. XP is 32-bit Professional. The FileNet Visual Workflo components are the last, version 3.6.

Does anybody have any experience with FileNet IDM on Windows 7, and/or dealing with performance problems that appear to be DLL related on Windows 7 - and suggestions?

ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
Timbuck
  • 325
  • 1
  • 8
  • 20

1 Answers1

0

It turns out that the performance issue was related to drawing a ListView on the screen. Making the ListView not visible while retrieving the data, and then drawing the ListView once all data was retrieved, greatly increased performance.

I'll chalk this up to differences between 32-bit and 64-bit systems.

Timbuck
  • 325
  • 1
  • 8
  • 20