While it's always been clear that an array of N elements uses less memory
than a hash of N key-value pairs, I actually sat down the other day with
MacPerl and tried to figure out the exact difference.  MacPerl is useful
because (due to limitations in MacOS) it has a quite fixed amount of memory
accessible to it (as opposed to running under an OS where apps could grab
or release any amount of core as needed).  So to test the memory usage of a
structure, you simply start MacPerl fresh, fill its memory with as many of
the structure as you can, and see how far you get before MacPerl screams
"Out of memory!" (at which point you should quit MacPerl, by the way).
Well, I found that the single-array structure I have been considering
moving to for storing arrays is more efficient than the hash-and-array
structure used currently, the difference was not as dramatic as I'd
expected.  (I was hoping for something like three times as efficent for a
typical element, but was nowhere near that.)  I'll see about posting the
exact tests and results Monday.

So, for the moment, I see no compelling reason to go changing the basic
type and content of Element objects.


HOWEVER:

* I'd appreciate any further reports of why users have found it necessary
(or at least convenient) to break encapsulation.

* Once I'm happy that noone's using the pre-XS HTML::Parser anymore (which
is not likely to be in the near future!), I may modify TreeBuilder to not
be OOP anymore; its basic documented interface would not change, but it
would interact with Parser thru callbacks, not methods.  This would break
EVERYTHING that uses TreeBuilder as a BASE class (instead of just using it
as is).  So if you have any module that says:
  @ISA = ('HTML::TreeBuilder');
please tell me 1) that you do so, and 2) why.

--
Sean M. Burke [EMAIL PROTECTED] http://www.netadventure.net/~sburke/

Reply via email to