🚀 go-pugleaf

rajinder.singh@novusmkt.com schrieb in Nachricht
<6shned$c44$1@nnrp1.dejanews.com>...
>I have a need to create a huge type library. I was wondering what memory,
>performance limitations I can run into. I wrote a program to create a
>type library and some dummy interfaces with methods on them. Here are the
>limits on the number of Interfaces and Methods I can have.
>Number of Interfaces : 1022
>Number of Methods Per Interface : 2207
>

The performance issues set aside, I would strongly encourage you
to througly revise your design approach. If you have more than
7 +/- 2 properties, 7 +/- 2 methods and 7 +/- 2 relationships on
the primary interface of an object, you should start reviewing
whether you could probably break up such an object into smaller,
self-contained parts which deal with a specific issue.

Even if you look at some of the more nasty interface monsters
you can find within Microsoft's COM itself (see IMoniker) you
will see that there are always only less than hand full of methods
(say: less than 5) which deal with the very same topic. As a
matter of fact, IMoniker was designed in the very early days of
COM and wasn't broken into smaller pieces just for optimization
reasons, if I remember right.

7 +/- 2 is a natural barrier in human thinking and this usually
reflects right into the object model. I just assume you guys are
making a terrible mistake regarding complexity there.


For the technical part: Yes, it will have dramatic negative effects
on performance if you use humongous type libraries like these,
because Automation is highly dynamic and traverses the type information
for each and every call anew. You can imagine that with type libaries
of this size, it will burn a considerable amout of "horsepower" just
to locate the required information every time over again. Also, the
type information is creating a pretty large number of structures
when loaded and with type libaries of that size, you're tying up a
considerable amount of memory there.


In short, I'd say: don't do that.



Clemens



--- it's just software, anything can be done ---
      Clemens F. Vasters - Software Architect
    OOA/OOD, COM/DCOM, Win32, ODBC
              clemensv@frogpond.org
-------------------------------------------------
     Composed, written and arranged on
     Microsoft Windows NT Server & IE4
-------------------------------------------------