On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in response to me:
> > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > . . . > Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to > get the widest possible audience of testers. It's a lot easier than hosting > it on a web site or whatever--for both the developer and the users. . . . True, true. You've convinced me. > > . . . . With (potentially) many modules having > > the same name and multiple authors/versions, the current complexity of > > the perl /lib tree could increase to the third power. That gonna be > > very disk-intensive for every frigging perl script that runs. > > See my earlier framework/bundle suggestion. I don't think it's that bad, > disck-access-wise. Sticking just to the disk-intensive issue for a moment -- Due to our judicious writing of modules, libraries, etc, we tend to have a lot have relatively simple (less than 1000 lines) scripts that do quite useful things for managing our network (sorry, can't talk about 'em -- proprietary software and all that sort of rot). Each tool does a direct use or require of about a half-dozen things, but our master modules and libs grab quite a few more. All in all I guestimate we're loading anywhere from 30 to 100 modules per `simple' tool run. With standard @INC plus our two or three more, that's 8-10 directory trees that must be searched. The current perl module naming schema means (essentially) one probe per directory per package until the module is found. Once it's found, all is done. 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. Only once we know what's available can we make an intelligent `most recent' decision. At a minimum, with 10 items in @INC we have a tenfold increase in number of dir reads. Then add in the checking for author, version, etc ... and we've got to either embed the author/version/release data into the file names (the horror, the horror) or open the individual modules and read the author/version/release data from each one (the horrorer, the horrorer). This very strongly argues towards indexes. My seat of the pants number say our current tools (which use DBI to access databases) spend about as 10% of their CPU and wall clock time in compilation. This is measured by deliberately running the tools with an error (bad switch) vs running it correctly and comparing the times. Go to a module/version/release seach pattern and a ten-fold minimum increase in serach time . . . and you double the tool run times. That's intolerable in our environment. 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. > > 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. > Disk space and RAM are cheap and getting cheaper. Think about what you mean > by "gigantic." Anyone who exhausts memory by running 150 different versions > of the Tk module at once deserves what they get ;) > > > On the other hand, there's no reason that shared libs couldn't be stored in a > > standard location and symlinked to. > > Yes there is: sanity! I think that's a foolish optimization. It makes > things much too fragile. Stuff like that already drives me nuts in regular > Unix OS/app installations. I picked Tk as my example because it *cannot* work with multiple versions of the shared libraries (the .so files, not the perl modules) simultaneously. Every window, every widget, every Ghu-knows-what down to a fairly low level must reside in the same context. If they don't, subwindows don't get managed properly, widgets from version X can't be attached to units from version Y, etc, etc. The same is almost certianly true of DBI modules, Gnome modules, and many others. The 6PAN installation tree and perl6 module builds must be able to deal with this issue. If they don't, then Larry's promise of the ability of simultaneous load is only going to apply to pure perl modules. But I don't think that's what Larry means, and I don't think it's a restriction we *have* to live with. Steve -- STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and forth three times, it is time to pick up the phone. from the 12-Step Program for email addicts, http://www.time.com/time/columnist/taylor/article/0,9565,257188,00.html
