Camillo, On 23 Apr 2012, at 16:26, Camillo Bruni wrote:
I figured a specific bottleneck of the current implementation of MC is the uniqe version name check.
On gemstone this takes 4 seconds! for the pharo inbox, definitely too longâ¦
That seems like a problem with the SS3 and/or GemStone server. I should be much faster: [ MCHttpRepository new parseFileNamesFromStream: (ZnClient new beOneShot; get: 'http://mc.stfx.eu/ZincHTTPComponents') readStream ] timeToRun 227 (this is for half that many versions, admitted cached in RAM on the mc.stfx.eu server)
The culprit can be found here
MCFileBasedRepository >> includesVersionNamed: aString ^ self allVersionNames includes: aString
assuming that the PharoInbox consists of quite some versions (currently 947) this is quite some overhead.
It would be possible to skip the check all together, and fail when there is a conflict. In a Distributed VCS you can never be sure anyway, right ? For me commiting is always slow due to my large package cache.
I would suggest the following improvements:
- add a specific includesVersionNamed: server-side service - add a simpler allVersionNames service that returns a newline separated list of filenames (not an html doc!)
Could be a solution I guess. But checking whether a version exists could be as simple as a HEAD request, no ? Then we would need almost no extra API, just a minor semantic change (with a fallback to a normal real GET). I don't know if the other format would really make much difference, but I have to admit it would be more logical.
By having specific MC repository implementations everything would be 100% backwards compatible since no services are removed nor is the default http repository implementation changed.
Probably doable.
what do you think?
BTW, do all repositories (actual, cache, others) have to be checked all the time ? Can't we at least turn that into an option ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill