[Pharo-project] Smalltalk for small projects only?

Chris Muller asqueaker at gmail.com
Sun Jan 29 22:31:24 CET 2012


But the goal of making the image smaller is congruent with the goal of
making Morphic smaller, which would be congruent with the desire for
Monticello to be "scalable".  So the solution should be smaller
packages, not more and bigger tools.

Besides, the measure of scale you've chosen is an build /
initialization step, which can much more afford to be "slow",
especially if the dream is to just have it sit and build 24 hours a
day.

A better non-scaling measure to recognize in Monticello, IMO, is using
FileBased repositories, which require enumeration of an ever-growing
number of versions for many of its operations.

Using a database-backed MC repository solves that.



On Sun, Jan 29, 2012 at 11:48 AM, Philippe Marschall <kustos at gmx.net> wrote:
> On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
>>
>>
>> On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>>
>>>> As for scale.. monticello scales well.
>>>
>>>
>>> No, it does not.
>>
>>
>> Please elaborate: I really can't see the difference between doing a merge
>> (either an easy one or a more diffucult one over multiple files, spread over
>> a couple of days, with intervening changes by others) using either
>> Monticello or Git.
>
>
> The scalability limits of Monticello are well understood. PackageInfo
> doesn't scale, at all. You put too many classes in a package, and
> snapshotting gets really slow. Don't believe me? Make a change in Morphic
> which has only 200 classes and save it.
>
> And it's not like loading is any faster. Seaside takes 10 minutes to build
> from locally cached [1] packages, only 12 seconds go to running tests [2].
> This makes C++ compilation times seem fast by comparison.
>
>  [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
>  [2]
> http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/
>
> Cheers
> Philippe
>
>



More information about the Pharo-project mailing list