Are Objects really hard?

There is no question that over-use of inheritance (failure to understand composition) is a classic beginner mistake.  That said, don't underestimate the value of inheritance.  Granted, the example I have in mind is perfect for specialization, but beyond that, failure to use (extensive) inheritance can at times lead to lots of duplicate code (which is really bad).  Say it once - inheritance can help one do just that (policy up, implementation down, etc.).

Bill

On 02/13/2012 12:22 PM, Sven Van Caekenberghe wrote:
>
> On 13 Feb 2012, at 10:23, Göran Krampe wrote:
>
>> PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
>
> I just tried in my 1.4 image #14329 image with the standard browser and it works:

Oh nice! I confess i didn't try the latest Pharo (only 1.2) before I
wrote this - I just presumed it still did not work ;) My bad.

regards, Göran

Hi,

2012/2/13 Göran Krampe <[hidden email]>:
I could not resist:
One should not presume much about Pharo because its evolution super-linear, and
we all know how poor we are at estimating such super linear models.

Cheers,
Doru


> regards, Göran
>



--
www.tudorgirba.com

"Every thing has its own flow"

I did analyse some of these "memory pumping effects" in Pharo. Come from overuse of "inheritance", that causes big objects with hundreds of methods to be created and garbaged, just for short tasks.

Better: "Composition over inheritance"!!!

Second problem is the "Liskov problem":

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

See PetitParser. Universal Tool. Fine. Blowing up memory unnecessarily. Moose ... ugh.

These *are* design flaws.

best, have fun, Guido Stepken

On Feb 13, 2012, at 2:47 PM, Guido Stepken wrote:

> I did analyse some of these "memory pumping effects" in Pharo. Come from overuse of "inheritance", that causes big objects with hundreds of methods to be created and garbaged, just for short tasks.
>

The number of methods do not influence *at all* the size on an object. Methods are on the class, the object point to its class, no need to allocate *any*
memory. The only thing that costs memory is *state*.

        Marcus

--
Marcus Denker -- http://marcusdenker.de

Ok. Then it must have been the ghost, that causes heavy "memory pumping", even under zero load, see CPU monitor.

Its quite difficult not to say *impossible* to run Pharo even for simple tasks within a small vserver account with 256 or 512 MB reserved or dynamically assigned memory space.

But i agree, that Smalltalk *can* be designed to run well within 1MB of RAM :-)

have fun, Guido Stepken

Hi,

On 13 February 2012 16:32, Guido Stepken <[hidden email]> wrote:
> Ok. Then it must have been the ghost, that causes heavy "memory pumping", even under zero load, see CPU monitor.

... so far for the "analysis". :-)

> But i agree, that Smalltalk *can* be designed to run well within 1MB of RAM

pah. 1 MB. Sheer luxury. 64 kB RAM, 256 kB Flash: Smalltalk running on
Lego Mindstorms NXT. Questions?

Michael ;-)

On 13 Feb 2012, at 16:32, Guido Stepken wrote:

> Its quite difficult not to say *impossible* to run Pharo even for simple tasks within a small vserver account with 256 or 512 MB reserved or dynamically assigned memory space.

This is ridiculous: a current stock Pharo server image (i.e. non-stripped) compares favorably with any other dynamic language.

  http://zn.stfx.eu/zn/index.html#livedemo

I am currently running 5 VM's on an AWS EC2 micro instance (613MB RAM, up to 2 ECU (1 ECU = the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor)).

Setup can also be quite simple:

  http://forum.world.st/Pharo-Core-HTTP-Server-OneCommandLine-Demo-td3702218.html#a3702245

Sven

Hi Michael,

Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even.

Tnx 4 your funny comment!

Have fun, Guido Stepken

Hey Guido, I thought you said you were leaving us! Just too hard to stay away, eh? :-)

The code is available here:
http://www.hpi.uni-potsdam.de/hirschfeld/projects/nxtalk/

Alain


On 13 févr. 12, at 17:12, Nick Ager wrote:

On 13 Feb 2012, at 17:25, Guido Stepken wrote:

> Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even.

Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it is only load balancing, but to know that you have to be able to read.

Furthermore, Apache serving static files is way faster than that, something most people know, you apparently not.

And just for the record: I am comparing Pharo with other dynamic languages for dynamically generated content.

Anyway, do you have anything useful to contribute ?

On 13 February 2012 17:53, Sven Van Caekenberghe <[hidden email]> wrote:
Course, trolls always have something extra to say :)

--
Best regards,
Igor Stasenko.

Am 13.02.2012 17:53 schrieb "Sven Van Caekenberghe" <[hidden email]>:
>
>
> On 13 Feb 2012, at 17:25, Guido Stepken wrote:
>
> > Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even.
>
> Of course I am not: Apache 2 mod_proxy doesn't do any caching at all, it is only load balancing, but to know that you have to be able to read.

Yes! http://httpd.apache.org/docs/1.3/mod/mod_proxy.html

Even dynamically growing cache memory.

Tnx 4 your comments. When you put *real* and *direct* load on Pharo (no tricks, no apache, no nginx in front), and you can see, what i mean: Memory pumping, eating up vasts mounts of memory at even low load (use ab -n 10000 -c 1000) ...

Ok, facts are unwanted here. Away again! :-)

Happy hacking!

Guido Stepken

> Furthermore, Apache serving static files is way faster than that, something most people know, you apparently not.
>
> And just for the record: I am comparing Pharo with other dynamic languages for dynamically generated content.
>
> Anyway, do you have anything useful to contribute ?

On 13 February 2012 18:09, Guido Stepken <[hidden email]> wrote: How about *real* and *direct* load on a sport car? Ever tried to haul
fuel cistern with it?
How fast it goes?
The answer to your issue is just one: use proper tools for solving
your problems.



--
Best regards,
Igor Stasenko.

On 13 Feb 2012, at 18:09, Guido Stepken wrote:

> Yes! http://httpd.apache.org/docs/1.3/mod/mod_proxy.html
>
> Even dynamically growing cache memory.

No!

This page

  http://zn.stfx.eu/zn/index.html#livedemo

clearly refers/links to

 http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

which refers/links to

 http://httpd.apache.org/docs/current/mod/mod_proxy.html

Where it is clearly stated that mod_cache is needed to add caching functionality (Apache 1.3 is different, old).

> Tnx 4 your comments. When you put *real* and *direct* load on Pharo (no tricks, no apache, no nginx in front), and you can see, what i mean: Memory pumping, eating up vasts mounts of memory at even low load (use ab -n 10000 -c 1000) …

I would be very surprised to learn that you have written and/or operated a dynamic website that was hit like that !

> Ok, facts are unwanted here. Away again! :-)

Bye.

Am 13.02.2012 18:17 schrieb "Igor Stasenko" <[hidden email][hidden email][hidden email]>:

> How about *real* and *direct* load on a sport car? Ever tried to haul
> fuel cistern with it?
> How fast it goes?
> The answer to your issue is just one: use proper tools for solving
> your problems.

Do the right things, make Pharo, Seaside *usable*

Look at: http://www.cyberport.de/notebook-und-tablet/notebook-berater/erweiterte-suche/liste.html

Selecting notebooks by price, endurance, weight, with sliders. I could sell *hundreds* of those shops to customers, big companies, hosting inclusive for 20.000 each.

Pharo/Seaside *is* the right tool if YOU WOULD DO THE RIGHT THINGS, not just bothering some class structure deep in Pharo.

Pharo hangs even at *directly* serving static pages at low loads. I hoped to see significant speedups due to lack of any 3/4/5 tier middleware with being everything done within one VM. Database, delivery, ...

I am still disappointed. Welcome in the *real world*. Doing academic brainfuck is not sufficient. So are your etats for developing Pharo, near ZERO. Start thinking like business men! Listen to that, what customers want!

tnx 4 understanding, Guido Stepken

Caching now has moved into Apache core. Is still there.

On 13 February 2012 18:59, Guido Stepken <[hidden email]> wrote: Seaside is separate project. It runs on multiple smalltalk dialects.
Now if you think that something in Pharo makes it slow or unusable,
feel free to identify and point out on problem,
open issue, report bugs, contribute fixes.

> Look at:
> http://www.cyberport.de/notebook-und-tablet/notebook-berater/erweiterte-suche/liste.html
>
> Selecting notebooks by price, endurance, weight, with sliders. I could sell
> *hundreds* of those shops to customers, big companies, hosting inclusive for
> 20.000 each.
>

And? Clicking on slider on that site takes 5 seconds for page to refresh.
Welcome to *real* world.

> Pharo/Seaside *is* the right tool if YOU WOULD DO THE RIGHT THINGS, not just
> bothering some class structure deep in Pharo.
>
> Pharo hangs even at *directly* serving static pages at low loads. I hoped to
> see significant speedups due to lack of any 3/4/5 tier middleware with being
> everything done within one VM. Database, delivery, ...
>
You lost me.

VM is not Seaside.
Not a database.
Not a web server.
And finally, not a notebook selling portal.
VM is general-purpose virtual machine. And it will always lose to
specialized software which
were originally designed for serving web under high loads.

So, again use right tools for your needs.

And good luck with waiting till 'speedups' will magically happen while
keeping trolling.

> I am still disappointed. Welcome in the *real world*. Doing academic
> brainfuck is not sufficient. So are your etats for developing Pharo, near
> ZERO. Start thinking like business men! Listen to that, what customers want!
>

> tnx 4 understanding, Guido Stepken


--
Best regards,
Igor Stasenko.