> As far as I know VB implements the Collection in C++ code in the
> runtime using a hashing algorithm.  Last year I was able to implement
> my "own" Collection in VB-6 using hashing, and the result ran 15%
> faster than VB collections.  When my boss saw it, he reminded me that
> Francesco Balena did this a number of years ago.  This shows that the
> key is not the language it is a cool algorithm which I used.

> There have been a number of instances where developers working purely
> in VB recreate system features that run faster than the Microsoft
> implementation.  A coworker heard a VSLive speaker in 1999 who'd
> implemented VB-compatible math in pure VB that ran faster than the VB
> runtime.

> What this entails may be only that the Microsoft developers have other
> fish to fry, or it may actually mean that not all good developers work
> for Microsoft.

> You do not have to use C++ to create a Collection object that
> outperforms the Collection object provided with the system: just use a
> better hashing algorithm.  Or, convert to VB.Net which has a range of
> improved collections including a hash table.

> What is Faster?
> (I need to use 'Key' search capability)

> Dictionary or collection?

> Thanks!

> What is Faster?
> (I need to use 'Key' search capability)

> Dictionary or collection?

> What is Faster?
> (I need to use 'Key' search capability)

> Dictionary or collection?

> Thanks!

> > > Hi,
> > > Does anybody know how VB implements the Collection. Is it possible to
> write
> > > a COM collection object using VC C++ that is faster than VB's
> Collection.
> > > Thanks,
> > > -Tony

> > As far as I know VB implements the Collection in C++ code in the
> > runtime using a hashing algorithm.  Last year I was able to implement
> > my "own" Collection in VB-6 using hashing, and the result ran 15%
> > faster than VB collections.  When my boss saw it, he reminded me that
> > Francesco Balena did this a number of years ago.  This shows that the
> > key is not the language it is a cool algorithm which I used.

> > There have been a number of instances where developers working purely
> > in VB recreate system features that run faster than the Microsoft
> > implementation.  A coworker heard a VSLive speaker in 1999 who'd
> > implemented VB-compatible math in pure VB that ran faster than the VB
> > runtime.

> > What this entails may be only that the Microsoft developers have other
> > fish to fry, or it may actually mean that not all good developers work
> > for Microsoft.

> > You do not have to use C++ to create a Collection object that
> > outperforms the Collection object provided with the system: just use a
> > better hashing algorithm.  Or, convert to VB.Net which has a range of
> > improved collections including a hash table.

>   Does anyone have an opinion about using a custom data type
> instead of a collection? Is there a limit to the number of members a data
> type can hold?

> --
> --


> > So..

> > What is Faster?
> > (I need to use 'Key' search capability)

> > Dictionary or collection?

> > Thanks!

> > > > Hi,
> > > > Does anybody know how VB implements the Collection. Is it possible to
>  write
> > > > a COM collection object using VC C++ that is faster than VB's
>  Collection.
> > > > Thanks,
> > > > -Tony

> > > As far as I know VB implements the Collection in C++ code in the
> > > runtime using a hashing algorithm.  Last year I was able to implement
> > > my "own" Collection in VB-6 using hashing, and the result ran 15%
> > > faster than VB collections.  When my boss saw it, he reminded me that
> > > Francesco Balena did this a number of years ago.  This shows that the
> > > key is not the language it is a cool algorithm which I used.

> > > There have been a number of instances where developers working purely
> > > in VB recreate system features that run faster than the Microsoft
> > > implementation.  A coworker heard a VSLive speaker in 1999 who'd
> > > implemented VB-compatible math in pure VB that ran faster than the VB
> > > runtime.

> > > What this entails may be only that the Microsoft developers have other
> > > fish to fry, or it may actually mean that not all good developers work
> > > for Microsoft.

> > > You do not have to use C++ to create a Collection object that
> > > outperforms the Collection object provided with the system: just use a
> > > better hashing algorithm.  Or, convert to VB.Net which has a range of
> > > improved collections including a hash table.

> >   Does anyone have an opinion about using a custom data type
> > instead of a collection? Is there a limit to the number of members a
data
> > type can hold?

> I'm unclear on the question.  I really hope you do not plan on
> implementing something like this:

>      Private Type TYPhorribleType
>           strMember1 As String                  ' Eeek
>           strMember2 As String                  ' Yow
>           strMember3 As String                  ' No
>           strMember4 As String                  ' Aieee
>           .
>           .
>           .
>           strMember999 As String                ' Blarg
>      End Type

> (I've seen horrors like this, often justified by appeal to corporate
> "needs", broadly construed, the need for people to act like idiots.)

> Perhaps you mean something like this

>      Private Type TYPcollectionType
>          strMember() As String
>      End Type

> that is, an array dynamically managed by the collection.  Here there
> is no apriori limit on the size.

> However, you can always create a non-collection user data type with
> the fields you want (such as name, address, city, state and zip) and
> then assign elements of this type to a straight collection.  This is
> the best way to implement collections of typed objects.

> > --
> > --


> > > So..

> > > What is Faster?
> > > (I need to use 'Key' search capability)

> > > Dictionary or collection?

> > > Thanks!

> > > > > Hi,
> > > > > Does anybody know how VB implements the Collection. Is it possible
to
> >  write
> > > > > a COM collection object using VC C++ that is faster than VB's
> >  Collection.
> > > > > Thanks,
> > > > > -Tony

> > > > As far as I know VB implements the Collection in C++ code in the
> > > > runtime using a hashing algorithm.  Last year I was able to
implement
> > > > my "own" Collection in VB-6 using hashing, and the result ran 15%
> > > > faster than VB collections.  When my boss saw it, he reminded me
that
> > > > Francesco Balena did this a number of years ago.  This shows that
the
> > > > key is not the language it is a cool algorithm which I used.

> > > > There have been a number of instances where developers working
purely
> > > > in VB recreate system features that run faster than the Microsoft
> > > > implementation.  A coworker heard a VSLive speaker in 1999 who'd
> > > > implemented VB-compatible math in pure VB that ran faster than the
VB
> > > > runtime.

> > > > What this entails may be only that the Microsoft developers have
other
> > > > fish to fry, or it may actually mean that not all good developers
work
> > > > for Microsoft.

> > > > You do not have to use C++ to create a Collection object that
> > > > outperforms the Collection object provided with the system: just use
a
> > > > better hashing algorithm.  Or, convert to VB.Net which has a range
of
> > > > improved collections including a hash table.

>    I need to hold 5 instances of about 30 values. At this point
> I'm using a class that instatiates 5 collections and provides
> Get and Let properties for those values. It works fine but it
> seems like an awfully bloated way to do it.
>    I can't use an array because I want names.
>      Another idea I thought of was to just instantiate multiples of a
> class that has 30 private variables. That also seems a bit messy,
>  but then I reason that the Collections must be doing a similar thing
> and why not cut out the middleman. Does that make sense?

> --
> --




> > > I'm no expert on this but it's something I've been looking into lately.
> > > According to Paul Lomax in VB & VBA in a Nutshell, a Dictionary is
> > > 2 to 3 times faster than a collection, depending on what you're doing.
> > > It's also easier to work with because you don't need to remove and
>  re-add
> > > a key just to change the value.
> > >   On the downside you have to ship SCRRUN.DLL, which needs
> > > MSVCRT.DLL, adding about 400 KB to the package.

> > >   Does anyone have an opinion about using a custom data type
> > > instead of a collection? Is there a limit to the number of members a
>  data
> > > type can hold?

> > I'm unclear on the question.  I really hope you do not plan on
> > implementing something like this:

> >      Private Type TYPhorribleType
> >           strMember1 As String                  ' Eeek
> >           strMember2 As String                  ' Yow
> >           strMember3 As String                  ' No
> >           strMember4 As String                  ' Aieee
> >           .
> >           .
> >           .
> >           strMember999 As String                ' Blarg
> >      End Type

> > (I've seen horrors like this, often justified by appeal to corporate
> > "needs", broadly construed, the need for people to act like idiots.)

> > Perhaps you mean something like this

> >      Private Type TYPcollectionType
> >          strMember() As String
> >      End Type

> > that is, an array dynamically managed by the collection.  Here there
> > is no apriori limit on the size.

> > However, you can always create a non-collection user data type with
> > the fields you want (such as name, address, city, state and zip) and
> > then assign elements of this type to a straight collection.  This is
> > the best way to implement collections of typed objects.

> > > --
> > > --


> > > > So..

> > > > What is Faster?
> > > > (I need to use 'Key' search capability)

> > > > Dictionary or collection?

> > > > Thanks!

> > > > > > Hi,
> > > > > > Does anybody know how VB implements the Collection. Is it possible
>  to
>  write
> > > > > > a COM collection object using VC C++ that is faster than VB's
>  Collection.
> > > > > > Thanks,
> > > > > > -Tony

> > > > > As far as I know VB implements the Collection in C++ code in the
> > > > > runtime using a hashing algorithm.  Last year I was able to
>  implement
> > > > > my "own" Collection in VB-6 using hashing, and the result ran 15%
> > > > > faster than VB collections.  When my boss saw it, he reminded me
>  that
> > > > > Francesco Balena did this a number of years ago.  This shows that
>  the
> > > > > key is not the language it is a cool algorithm which I used.

> > > > > There have been a number of instances where developers working
>  purely
> > > > > in VB recreate system features that run faster than the Microsoft
> > > > > implementation.  A coworker heard a VSLive speaker in 1999 who'd
> > > > > implemented VB-compatible math in pure VB that ran faster than the
>  VB
> > > > > runtime.

> > > > > What this entails may be only that the Microsoft developers have
>  other
> > > > > fish to fry, or it may actually mean that not all good developers
>  work
> > > > > for Microsoft.

> > > > > You do not have to use C++ to create a Collection object that
> > > > > outperforms the Collection object provided with the system: just use
>  a
> > > > > better hashing algorithm.  Or, convert to VB.Net which has a range
>  of
> > > > > improved collections including a hash table.

>    I need to hold 5 instances of about 30 values. At this point
> I'm using a class that instatiates 5 collections and provides
> Get and Let properties for those values. It works fine but it
> seems like an awfully bloated way to do it.
>    I can't use an array because I want names.

> > Yes, I'm afraid I was thinking of the TYPhorrible type! It did seem
> > like a messy idea but I've been trying to think of something more
> > efficient than what I've got.

> >    I need to hold 5 instances of about 30 values. At this point
> > I'm using a class that instatiates 5 collections and provides
> > Get and Let properties for those values. It works fine but it
> > seems like an awfully bloated way to do it.
> >    I can't use an array because I want names.

> Use an Enum to hold the names, perhaps something like this:

>  URL:http://groups.google.com/groups?selm=ORaIm8j1BHA.2212%40tkmsftngp05

> --
> Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check!

> > Thank you. That's an interesting design. I gather, then
> > that using variables in a class IS more efficient than
> > a collection? I don't have a grasp of what difference there might
> > be in how the memory is handled but assumed that a collection
> > has to be at least as indirect, and at least as memory intensive,
> > as variables accessed through a class.

> Collections are pretty expensive, but it'll be faster than the
> approach I used if there are a /lot/ of items/properties!  There
> are ways to speed up my Items "property", though, such as using
> a binary search or "minimal perfect hash function" on Index when
> it's a string, so the Select Case is always done on a number,
> though it's usually pointless for less than a dozen or so items:

> private type luentry
>   key as string
>   num as long
> end type

> private function lookup(byref index as variant) as long
>   static lu() as luentry, initialized as boolean

>   if not initialized then
>     redim lu(0 to 3)
>     ' make sure the keys are in sorted order!
>     lu(0).key = "firstname"
>     lu(0).num = sffirstname
>     lu(1).key = "id"
>     lu(1).num = sfid
>     lu(2).key = "lastname"
>     lu(2).num = sflastname
>     lu(3).key = "registered"
>     lu(3).num = sfregistered
>     initialized = true
>   end if

>   if vartype(index) <> vbstring then
>     lookup = index
>     exit function
>   end if

>   ' Binary search is harder than it seems -- according to Knuth,
>   ' the first version was published in 1946, but the first /correct/
>   ' version wasn't published until 1962, /six{*filter*} years/ later!
>   dim l as long, u as long, m as long
>   l = lbound(lu)
>   u = ubound(lu)
>   do
>     m = (l + u) \ 2
>     select case strcomp(index, lu(m).key, vbtextcompare)
>     case is < 0
>       u = m - 1
>     case is > 0
>       l = m + 1
>     case else
>       lookup = lu(m).num
>       exit function
>     end select
>   loop while l <= u
>   lookup = -1
> end function

> public property get fields(byref index as variant) as variant
>   select case lookup(index)
>   case sfid
>     fields = id
>   case sflastname
>     fields = lastname
>   case sffirstname
>     fields = firstname
>   case sfregistered
>     fields = registered
>   case else
>     err.raise number:=5
>   end select
> end property

> --
> Joe Foster <mailto:jlfoster%40znet.com>     Got Thetans?