Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
j.merrill	XInfo performance speedup Posted: Sunday, May 23, 2004 6:50 PM (EST) I'm wondering whether just attempting to use the ActiveX object in question (with #ELX set appropriate) might work. Even if you're planning to (e.g.) run REGSVR32 if the object isn't installed, can it hurt to try to load the ActiveX you need? The real answer, BTW, is that XInfo has no good way to "shortcut" the process -- huge gobs of registry data need to be examined. (Run RegMon from sysinternals.com during an XInfo run to see what I mean.)
davin.church	XInfo performance speedup Posted: Tuesday, May 25, 2004 1:14 PM (EST) Trying to create the component is the alternative method I use, but it's often a pain (especially if you have to also create parentage for it).  And it too can be slower than I would like.  I was looking for an easier way if I could find it.   And reregistering a component won't work for me because in some cases I'm just asking if something's available, not trying to make it available (as it may not even be on the machine or I won't know where it is).   For shortcutting, it depends a lot on how the work is being done.  I haven't done any monitoring yet (though I should to get a better idea of the process), but here are some wild thoughts out of nowhere...   Just guessing from the speed of the process, it looks like it might be getting the entire list of objects from the registry, and then filtering that list to only return what you want.  If that's occurring, then this seems wasteful with large registries.  How about just reading the registry keys alphabetically (or quickly simulating it) and picking out just the names requested and ignoring any others.   Or, it also seems like each object has to get data from the registry in pieces, with different information coming from different places.  So what if you determined which components you want first, and then go get the extra information only for the components requested (rather than the entire list, I'm assuming).   But I guess most the useful and quickest thing to do would be to provide a way just to see if a component with an exact (non-wild-card) name exists or not.  That should be very easy and run very fast.  It wouldn't even have to return its information in cases like this, just a boolean.  I could probably arrange to do this kind of thing with a separate registry-management function, but that would keep me from being able to write stand-alone utilities that need this capability.
davin.church	XInfo performance speedup Posted: Tuesday, May 25, 2004 1:22 PM (EST) While I'm asking, here's another feature I think would be useful.  When returning the XInfo matrix, how about an additional column of data containing the path & file name of the DLL/OCX file that the control is using.  It should be easily available from the registry but isn't (AFAIK) stored anywhere else in the system.  I often want to go check the file's version numher (or its presence or other information) before using it, so easy access to the name would be a great help.   (I'd expect this to only be needed in relatively controlled environments, so reading the registry directly might be an acceptable solution.  But if it's easy to add to XInfo, then why not?)
Brian.Chizever	XInfo performance speedup Posted: Tuesday, May 25, 2004 1:48 PM (EST) The problem with putting this into XInfo is that it would slow it down.  XInfo may be returning hundreds of rows and you only need this information for one or two of them.   If you're not sure of how to get this information, look at the OCXPath function in the registry.w3 workspace given out at the 2003 User Conference.  It takes an argument of either a CLSID or a name from the first column of XInfo.   I wrote this using the APL2000.RegKey object, but if you have your own registry access functions, it would not be hard to convert it.
davin.church	XInfo performance speedup Posted: Tuesday, May 25, 2004 2:36 PM (EST) I agree, Brian, that calling a separate registry-handling routine would solve most such situations.  But it'd be handy to have it built-in for those times when it wasn't so convenient (such as when trying to write a standalone utility function).   As for the speed, if you're returning hundreds rows anyway, it's already going to be really slow.  If you don't care about the speed of that as it is, then it probably isn't going to hurt you to make it 20%-50% slower.  Who bothers to get an XInfo of their entire system anyway??  But for most uses, you're only going to want that for one (or a few) entries, so the overhead in fetching the extra info in that case should be insignificant.   But this is just a suggestion to help make things a little easier -- it's not a critical issue.