An MC challenge: As a practical matter what size package is best when using MC.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

An MC challenge: As a practical matter what size package is best when using MC.

Jerome Peace

In the context of maintaining squeak as packages:

-What is the largest practical package to store (and
load) as an MC package.

-What is the smallest practical package to store
separately (and load) as an MC package.

You can name whatever parameter for size that you
want.
(Bytes, Classes, Messages, Or Class>>Methods )

The practical aspect is in terms of resources.
Programmer time mostly. But this is affected by how
much memory the image has to have allocated to it to
successfully load the package.

I early on tried to save Morphic as a package (even
before it was split) with time consuming and then
disastorous results. (My iMac has about 100M allocated
to squeak.) Even maxing out the allocation ( which for
my resources stopped at ~200M) just used up more time
for no greater result. So I am of the learning that MC
does (or at least didn't) scale well.

On what scale does it work admirably.

On what scales does it fail to work well?


Yours in curiosity, -- Jerome Peace



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: An MC challenge: As a practical matter what size package is best when using MC.

Colin Putney

On Aug 27, 2006, at 1:30 AM, Peace Jerome wrote:

> So I am of the learning that MC
> does (or at least didn't) scale well.
>
> On what scale does it work admirably.
>
> On what scales does it fail to work well?

You're right, Monticello doesn't scale well.

However, your questions are impossible to answer. It depends on how  
fast your machine is, how much memory it has, how fast your net  
connection is (if you're using a remote server), how fast the server  
is, what your personal tolerance for UI responsiveness is, and what  
version of Monticello you're using.

You might also be affected by particularly high tides, proximity high  
tension power lines, and the amount of walrus blubber in your diet.

Seriously, the biggest factor is probably the combined number of  
classes and methods in your packages. If you can keep your packages  
from getting too big, it should work fine. Note that breaking large  
packages into several smaller packages should improve things. It also  
helps if you make small, frequent commits, rather than bunching up  
lots of changes into a single commit.

Hope this helps,

Colin

Reply | Threaded
Open this post in threaded view
|

Re: An MC challenge: As a practical matter what size package is best when using MC.

Philippe Marschall
2006/8/27, Colin Putney <[hidden email]>:

>
> On Aug 27, 2006, at 1:30 AM, Peace Jerome wrote:
>
> > So I am of the learning that MC
> > does (or at least didn't) scale well.
> >
> > On what scale does it work admirably.
> >
> > On what scales does it fail to work well?
>
> You're right, Monticello doesn't scale well.

One of the reasons Monticello doesn't scale well it because Squeak
doesn't scale well. Example when loading a Monticello package:

12 % of the time are spent doing nothing (Delay wait) because Squeak
figures out the mouse position. Every time it does that, it does 2 ms
of waiting.
30 % of the time Squeak is figuring out the category of a class. This
is so slow because it has to scan linearly over an array.

Philippe