Michael G Schwern wrote:
> Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of the lookup is
done at compile time rather than runtime... so I'm not sure what is similar
about the mistaken logic... for arrays, more of the lookup is done at compile
time rather than runtime, and this would be true of psuedo-hashes as well.
> it would seem that the
> > variability in write references could still make this pay off. The
> > set_const is about 40% slower for hash, and set_var is about 166%
> > slower.
>
> Accessor overhead swamps all.
So let's posit you've cured the accessor overhead problem. Now we're left with
set_const being 40% slower for hash, and set_var 166% slower for hash. Still
want to ignore it? Why?
> Its just benchmarking flutter. I reran it with 1 everywhere else and
> the same results. Besides, because $aobj is global, the first call
> would extend the array and the following 899_999 wouldn't worrry about
> it.
OK. Just checking.
> > > I know, lets call it a pseudo-hash!
> > >
> > > Been there, done that, worn the scars proudly.
> >
> > Is _that_ what a pseudo-hash is? Then it sounds like a good idea.
> > But maybe there are some differences between today's pseudo-hash and
> > my proposal, even though they might be similar. I think mine is
> > pretty general, and the discussion on this list made it sound like
> > pseudo-hash has some other restrictions?
>
> Read RFC 241 for a brief overview of pseudo-hash problems.
I've already read RFC 241. Re-reading in this context results in the following
comments/quests for information. The remaining quotes here come from RFC 241...
> Doesn't play well with multiple inheritance
>
I can sure believe this. There'd be indexes from multiple base classes. I
don't know how Perl does multiple inheritance anyway, so I can't comment
effectively on whether this is or would be a problem. If Perl does multiple
inheritance, I haven't stumbled across the documentation for it, but neither
have I looked. I don't use multiple inheritance.
> Muddles the behavior of typed variables
>
Not sure what this means.
> Requires significant extra documentation and complication of
> hash operations.
>
I've used perl for some years, and never noticed pseudo-hashes from the user
perspective. Is this an internals only issue? Or what else have I missed?
My proposal is different, because it would require additional complication of
array operations. Hashes wouldn't be affected at all. Arrays would be
augmented with an internal hash (probably) to do the key to index translation at
compile time, the run-time code wouldn't notice that. If the key comes in as a
var, then the run-time code would have to deal with that. There'd be some
complication regarding string indexes that contain numbers: probably the names
used as keys should not be allowed to start with a digit, in my proposal, to
disambiguate proper processing.
> Inconsistencies between typed and untyped access.
>
I don't know what this means, either.
> Pseudo-hashes, unless used very carefully, often turn out slower
> than hashes.
>
Maybe so. I'm not sure why, or why not, or what all the restrictions on
pseudo-hashes are.
> Pseudo-hashes were added to solve three problems: restrict keyspace,
>
Not part of my proposal.
> reduce memory usage
>
Not part of my proposal. May be a side effect, I doubt it, though.
> and increase speed of hashes.
>
My proposal would allow name to key lookups, as an alternative to hashes, as a
hopefully faster alternative to hashes, but would not affect the speed of
hashes.
> There are many RFCs
> which address these issues with less caveats.
>
After looking at these points, I'm missing how you jumped to the conclusion that
I'm proposing pseudo-hashes.... they seem quite different than my proposal in
many details.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
