[MERGE] windows standalone installer creates and uses "plugins" directory for system-wide plugins (#129298)

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> Alexander Belchenko ?8H5B:
>>> Robert Collins ?8H5B:
>>>> Robert Collins has voted approve.
>>>> Status is now: Approved
>>>> Comment:
>>>> I think this is ok, however it's a bit strange that setting the plugin
>>>> path by hand will remove the system wide plugins directory; thats not
>>>> how it works on linux. If you have time I'd rather see you always append
>>>> the system wide location (which is bzrlib's own plugins dir on linux)
>>>> rather than only apply if if the user hasn't supplied their own path.
>>>> I suggest this so that bzr will behave the same on windows and linux
>>>> when a user does BZR_PLUGIN_PATH=XXX
>>> Hmm. Interesting.
>>> I'm thinking about BZR_PLUGIN_PATH and its masking effect, but...
>>> May I go a bit further and ask provoking question?
>> Actually in my testing loading plugins from zip is at least 2 times slower
>> than from filesystem.
> 
>>> May be we should move standard built-in plugins (err, very funny pun indeed)
>>> [I mean launchpad and multiparent] into this system-wide directory as well
>>> and simply disable our load-plugins-from-zip support?
>> IMO it make sense in term of speed-up (not very big actually 30ms vs 70ms on NTFS,
>> or vs 90ms on FAT32). I'll do it in next patch.
> 
> Interesting. Especially considering the setuptools (easy_install) stuff claims
> that scanning through zip files is faster than scanning through the filesystem.
> (Which is why they prefer to use eggs extensively.)
> 
> I could see that if python has cached the zip header in memory, it doesn't have
> to stat the filesystem, and can just probe the in-memory index.
> 
> However, what I remember from eggs is that they add another record to the
> search path, which means 1-more place that gets probed for every egg you have.
> (And probing 200 eggs doesn't seem like it could be faster than probing 1
> filesystem.)

In my understanding we have penalty from parsing library.zip directory content.
Currently library.zip that contains bzrlib and big part of Python standard library
as well as additional libraries has size 9.9MB. This zip file contains 910 files
inside. Our loading-plugins-from-zip code opens this zip, obtains all paths
inside zip and then select only those started with bzrlib/plugins. And only
then we using stadard zipimport mechanism. So our implementation is not the same
way setuptools used.

Probably we get performance penalties on reading zip-file and filtering its content.
IMO moving this plugins out of zip is better match for new system-wide policy
I've introduced. And this moving will be doing at the stage of building installer,
and therefore will be fully automated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHUYYazYr338mxwCURAoDrAJ9vlE9GoP/I9vxviCtJsSjFlD+gOwCfdmJc
e8VuohVeIOsjmpULi6b45Lc=
=en1o
-----END PGP SIGNATURE-----