On 6/5/02 2:59 PM, Steve Simmons wrote:
> Sticking just to the disk-intensive issue for a moment --
> [...]
> With the new one, we seem to have agreed that `most recent' will be
> used, not `first found'. That means that every tree must be probed,
> and probed with globs or sub-searches to match the various author,
> version, $RELEASE, etc stuff.
> [...]
> I recently spent a solid month peeling 9 seconds of per-tool overhead down to
> 1 second, getting a documented(!) savings of 16.25 hours *per week* in our
> operations group. The prospect of losing that time again with perl6 is, er,
> not acceptable. Again, this argues towards indexes.
More generally, I'd just call it caching. This can be done in many ways:
cached "flattened" bundle files, traditional indexes, or even simply another
module that does some (or all) of this for you, when needed, by augmenting
the "use" implementation with its own cached information:
use Module::Cache;
use Foo; # subsequent "use"s are faster now! :)
use Bar;
...
There may be some bootstrapping issues, but so far everything in Perl 6
seems up for "user replacement/augmentation." Why not "use" as well? :)
>>> The current perl module tree is pretty difficult for the average day to
>>> day scripter to comprehend. I'd go even further and say that it's so
>>> complex as to be unmanagable.
>>
>> Encapsulating by module would make the structure pretty easy to understand,
>> IMO.
>
> Yes, that would help with the understanding. It would not help with
> the search time overhead.
But that's fixable. It's much harder to make an inherently confusing (but
"fast") on-disk organization "more understandable", IMO :)
-John
