punkish has asked for the wisdom of the Perl Monks concerning the following question:

I have been working with Win32::OLE mostly successfully, but with numerous hurdles that I will summarize below. Perhaps you might have ideas for workarounds/solutions.

1. COM chews up a lot of memory and pegs the CPU. Not an issue for short processes, but for long processes, the memory heap keeps on building up, and then eventually quits... I get a funky "Smart Heap Library" error -- obviously not very "Smart," Of course, the computer also gets extremely sluggish (does Windows had a 'nice' equivalent for COM?). So, I am trying to FreeUnusedLibraries and Uninitialize (methods in Win32::OLE) and re-initialize, but am not sure if it is helping.

2. Seems like VB/COM has a latency that the OS doesn't seem to respect. Here is what happens --

a. do something with COM b. do something as a result of #1

One would expect that #b above would be carried out ONLY when #a above has cleanly ended. Well, apparently not. #a is started, the OS thinks it is done, and passes command to #b, but #a is still chugging along. These race conditions are unpredictable. I have been experimenting with

Win32::OLE->FreeUnusedLibraries(); Win32::OLE->SpinMessageLoop(); sleep 5;

but, as I said, these race conditions are unpredictable. Typically, I encounter this when I delete something in a directory 'dir' (#a above), and then do something (#b) that expects an empty directory 'dir', but #b comes back and says that the directory 'dir' is still not empty. I can change sleep 5 to sleep 10, but never any guarantee.

3. File/folder permissions. This is a strange one. I get an erro if I do the following --

a. mkdir(folder) b. put something in that folder c. do something with stuff put in #b above or confess

The error is akin to "stuff doesn't exist" even though it is clearly there, and file tests pass successfully. My process croaks and I restart. Since this time the folder already exists, I don't encounter the error. This happens consistently, and without any intervening changes to the permissions. I've got around this by pre-creating folders, but then I can't use any logic that depends on existence or absence of folders.

--

when small people start casting long shadows, it is time to go to bed

Replies are listed 'Best First'.
Re: cpu, memory, and permissions issues with Win32::OLE
by starbolin (Hermit) on Aug 19, 2006 at 07:52 UTC

    Wow, that's a lot. Taking it one at a time.

    "1. COM chews up a lot of memory and pegs the CPU. "

    .COM is known to be a hog but it shouldn't be that bad though. .COM is known to do that if asked to do to much at once. What is your program trying to do when the CPU pegs? I think your other perfomance issues might be related to this one.

    does Windows had a 'nice' equivalent for COM?"

    Yes .NET, but it's an incremental improvement only.

    I have been experimenting with:
    Win32::OLE->FreeUnusedLibraries();
    Win32::OLE->SpinMessageLoop(); sleep 5;

    This is sure to cause more problems at this point. Better to find out what's causing the original problem and fix that. The FreeUnusedLibraries hack still can take time to deallocate all the modules and will only cause things to run more slowly if you are not truely done with everything.

    As to the other problems you mention; my ESP powers tell me they are related to .COM getting behind with what your telling it to do. This might or might not be the case if my ESP is faulty.

    Did you know the debugger from the .NET SDK can be used on .COM objects?


    s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
Re: cpu, memory, and permissions issues with Win32::OLE
by BrowserUk (Patriarch) on Aug 19, 2006 at 09:30 UTC

    Do a Google for "Smart Heap Library". You get lots of hits and most of them seem to be memory errors and fixes for same. Perhaps the problems are inherent in what you are doing, or can be fixed by updating the COM libraries you are using.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: cpu, memory, and permissions issues with Win32::OLE
by Anonymous Monk on Aug 22, 2006 at 12:57 UTC
    COM works with reference counting (so does perl). That is usually good. It turns bad if your objects reference its parent. Then neither one will be deleted. Even FreeUnusedLibraries() doesn't help (mind the 'unused' in the name) because they are considered used by the other object. Because many COM-objects need to know their parent, they have a Set...Site() function (mostly the parent is called somthingSite in COM). Before unreferencing, you should call this with a NULL-Pointer, if you called it before to set a Site. Even if the function is called by another name, I would check for retained references.