1. Forum
  2. Usenet
  3. COMP.OS.MS-WINDOWS.PROGRA

  • calls to ActiveX components I wrote are slow. What could be causing it

    From R.Wieser@21:1/5 to All on Tue Dec 14 08:44:20 2021
    Hello all,

    Over time I've been writing a few ActiveX components, but have to notice
    that calls to it are, in comparision to system components like the
    dictionary one, rather slow.

    Case in point, I've got a loop which goes thru a dictionary object and
    compares the key against something retrieved from an ActiveX component I
    wrote. When I read from my ActiveX component before the loop and put it in
    a temp var and use that inside the loop the speed gain is /at least/ a
    factor of 10 ...

    It also doesn't matter if what I read is complex (a converted-from UTF-8 string) or simple (a value like a boolean), meaning the problem is (likely)
    not in those functions.

    The problem is that I've got no idea where to look/what to look at. :-(



    I do remember having read about some sort of caching mechanism related to
    the "GetIDsOfNames" function (not fully sure if that was the one), but have found nothing in that regard. Also, I'm offloading the work to the TypeInfo object, which I assumed would handle stuff like that.

    Bottom line:
    I need a pointer or two to where/what to look at to speed-up my ActiveX
    objects handling of calls to it.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Tue Dec 14 13:58:38 2021
    I fully forgot to mention that I'm calling the objects from within a bit of VBScript, and the object itself returns integers, longs and BStrings (no variants).

    I've also tried to see how my and a dictionary object respond to a being
    called by a simple program using the objects "Invoke" method. I measured
    the time it took to do 0x1000 calls, and did not see any significant
    difference between the two.

    IOW, no indication of a slowdown. :-|

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JJ@21:1/5 to R.Wieser on Wed Dec 15 21:55:22 2021
    On Tue, 14 Dec 2021 08:44:20 +0100, R.Wieser wrote:
    Case in point, I've got a loop which goes thru a dictionary object and compares the key against something retrieved from an ActiveX component I wrote.

    How many keys are in the dictionary?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Dec 15 17:37:57 2021
    JJ,

    How many keys are in the dictionary?

    Currently about 650. How's that important ?

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Thu Dec 16 14:39:11 2021
    JJ,

    To double-check I tested that "for each" dictionary loop with "foo = oDict.count" and also with "foo = oMyObject.DummyFunc" (doing nothing than returning a boolean) inside. When using the former the loop went
    considerably faster than when using the latter.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Jan 3 20:56:34 2022
    Over time I've been writing a few ActiveX components, but have to notice
    that calls to it are, in comparision to system components like the
    dictionary one, rather slow.

    Although I switched all debugging output off (making those calls disappear
    in the outputted executable), I didn't disable the functions which created
    the strings fed to the debugging output.

    In my case that was a GUID-to-string (outputted) followed by a lookup in the HKCR\CLSID branch in registry for the its name (also outputted). Removing those too made all the difference.

    ... and all I needed to do to figure the above out was to write some code to intercept all method calls to the Dictionary object (to see what-and-how it
    was called and than maybe try to mimick it), which included the same
    debugging output - and thus the same slow-down.

    Murphy's Law struck again : double-check that what you're sure of can't be
    the cause isn't the cause anyway. :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)