GuilhemBichot wrote:
> We can go two ways:
> 1) make it a duplicate of 153787, which is to say, we'll fix the additional 2a slowness when we fix 153787, which isn't assigned. This means that MySQL won't upgrade to 2a before a long time (I cannot sell a 2a upgrade to colleagues if the slow annotate becomes twice slower).
> 2) evaluate whether fixing only the additional 2a slowness is possible, and possible now, and if so, do it, then we can consider upgrading to 2a.
>
I should mention that I did spend a fair amount of time here when we
introduced 2a. (It used to be more like 10x slower.) I'm pretty
confident that I reached the limit of what we can achieve without
creating an on-disk cache of intermediate steps.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GuilhemBichot wrote:
> We can go two ways:
> 1) make it a duplicate of 153787, which is to say, we'll fix the additional 2a slowness when we fix 153787, which isn't assigned. This means that MySQL won't upgrade to 2a before a long time (I cannot sell a 2a upgrade to colleagues if the slow annotate becomes twice slower).
> 2) evaluate whether fixing only the additional 2a slowness is possible, and possible now, and if so, do it, then we can consider upgrading to 2a.
>
I should mention that I did spend a fair amount of time here when we
introduced 2a. (It used to be more like 10x slower.) I'm pretty
confident that I reached the limit of what we can achieve without
creating an on-disk cache of intermediate steps.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt 0HLAACgkQJdeBCY SNAAMenQCfXV0/ plBrHwrqyxvnpxl gdSo3 oa4pi6jcveBnuq8 vw
YYQAoMbcQ10gjCG
=JIh5
-----END PGP SIGNATURE-----