Date and Timestamp comparison

My original post wasn't just about Pollock performance, but about the state
of support for Pollock and also what I see as misprioritization of goals in
Pollock development.

> IMO, there's two different kinds of performance "optimization". If there
> is a requirement that something executes in x milliseconds, then making
> the code run fast enough such that it meets this target is not
> optimization, but fixing a bug. Continuing to tune for speed when the
> requirements are already fulfilled is what I would think of as
> optimization.

Well, since it has been admitted that performance tuning work hasn't been
done at all I guess we can dispense with the concern that overoptimization
is a concern.

The most glaring speed issue here is that text editing widgets don't even
nearly keep up with keyboard and mouse input.  This is apparently not a bug
in the widgets themselves, but in the underlying frameworks.  The slowness
is general, but most evident in the case of text editing widgets.  When
running on Windows or Linux the problem is hard to detect on new PCs (but
obvious running on Pentium 3 CPUs), but on even the fastest G4 Macintosh it
is painfully evident as typed characters appear at about one per second.
:-(  A tenfold speed improvement would still be too slow, but also a world
better.

So, I think it's embarrassing for Pollock that a simple text edit widget
doesn't keep up with its user on a 1.5GHz computer, especially considering
that a 10MHz 80286 machine running Smalltalk/V didn't have this problem.

Let's not put off addressing this issue.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 

Hi,
I absolutely agree about considering the performance of Pollock not a minor
problem but a serious bug.
There are a set of consideration about that:
1) if Pollock is not usable because of performance, that's a bug (as stated
by lot of other people on several mails). We are not talking about
milliseconds.
2) if you fix the more evident performance problem late, you save resource
(probably), but you can also discover that there is a serious architectural
issue impacting performance, and at that time, would be a bit late. ( I
don't know in the field of GUI design, but on the real time world, like
factory control, I had performance problems due to architectural choices
that forced me to change may thinking about the resolution)
3) if performance impact on usability, people don't use Pollock, and Cincom
miss a great opportunity of having the community playing, using, test,
improve (by suggestion ) the tool.

Please take in consideration that a lot of bugs have been discovered by some
of the small number of early adopters, and these bugs where there also on a
strict XP text first environment.
Could not be that, having a bit more stable API (as promised by Sames one
years ago), and the minimum of usability on the performance side, you
(Cincom) will gain time because of the (direct or indirect) community
support due to a larger use of pollock on experimental project or also in
preproduction project?

Pollock looks great, we would like to use it.

Ciao

Giorgio ferraris



 




-----Messaggio originale-----
Da: Carl Gundel [mailto:[hidden email]]
Inviato: lunedì 31 luglio 2006 17.04
A: VW NC
Oggetto: Re: Pollock rant

My original post wasn't just about Pollock performance, but about the state
of support for Pollock and also what I see as misprioritization of goals in
Pollock development.

> IMO, there's two different kinds of performance "optimization". If there
> is a requirement that something executes in x milliseconds, then making
> the code run fast enough such that it meets this target is not
> optimization, but fixing a bug. Continuing to tune for speed when the
> requirements are already fulfilled is what I would think of as
> optimization.

Well, since it has been admitted that performance tuning work hasn't been
done at all I guess we can dispense with the concern that overoptimization
is a concern.

The most glaring speed issue here is that text editing widgets don't even
nearly keep up with keyboard and mouse input.  This is apparently not a bug
in the widgets themselves, but in the underlying frameworks.  The slowness
is general, but most evident in the case of text editing widgets.  When
running on Windows or Linux the problem is hard to detect on new PCs (but
obvious running on Pentium 3 CPUs), but on even the fastest G4 Macintosh it
is painfully evident as typed characters appear at about one per second.
:-(  A tenfold speed improvement would still be too slow, but also a world
better.

So, I think it's embarrassing for Pollock that a simple text edit widget
doesn't keep up with its user on a 1.5GHz computer, especially considering
that a 10MHz 80286 machine running Smalltalk/V didn't have this problem.

Let's not put off addressing this issue.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 

The text editing speed has greatly improved in the last one or two releases
- I was supprised, that it is now almost what you would expect.

Except - having dynamic scrollbars enabled (which is what we usually want
:-) is the performance killer in the moment.

Cheers,
        Christian

> The text editing speed has greatly improved in the last one or two
> releases
> - I was supprised, that it is now almost what you would expect.

What kind of hardware are you using?  Have you tried it on Mac OS X?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 

Isn't Mac OS X VM much slower than other VMs in general?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Carl Gundel [mailto:[hidden email]]
Sent: Monday, July 31, 2006 9:04 AM
To: [hidden email]
Subject: Re: Pollock rant

> The text editing speed has greatly improved in the last one or two
> releases
> - I was supprised, that it is now almost what you would expect.

What kind of hardware are you using?  Have you tried it on Mac OS X?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 

> Isn't Mac OS X VM much slower than other VMs in general?

Yes, it isn't *that* slow.  The Wrapper UI isn't slow on old Macs and so why
should Pollock be slow on new ones?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl Gundel wrote:
> My original post wasn't just about Pollock performance, but about the
> state of support for Pollock and also what I see as misprioritization of
> goals in Pollock development.
>
>> IMO, there's two different kinds of performance "optimization". ...

Yes, that's true, we should not push the discussion into the direction
of performance issues only. That was just one point which I wanted to
comment on, as (like Giorgio Ferraris) I have had bad experiences with
not addressing performance problems early enough.

Could the support and prioritization issue be turned into a win-win
situation if Pollock would be promoted to something like a "beta
version" status? That could for example consist of registered early
adopters getting a certain level of support - certainly lower than for
production code - and maybe more influence on the schedule and
priorities, in exchange for a certain level of contribution to
development - e.g. participating in occasional chat sessions on
prioritizing (as a replacement for the XP on-site customer), submitting
bug fixes and enhancements, etc. Okay, many of you probably already send
bug reports and patches to Cincom, so it would be up to Cincom to say
what they would find a worthwhile compensation for support. The extent
of Pollock adoption might be taken into account for Cincom's
win-calculation.

That's just a suggestion from an outsider and non-Pollock-user. If it's
already happening or if it's completely besides reality, forget about
it. :-) Other ideas?

Joachim Geidel

Notebook, Pentium M, 1.4 GHz, 0.5 GB ram, WinXP SP2
Not the speediest...

Dont have a Mac (no business case for me :-)...

Cheers,
        Christian

>Notebook, Pentium M, 1.4 GHz, 0.5 GB ram, WinXP SP2
>Not the speediest...
>
>Dont have a Mac (no business case for me :-)...

On my 1.8GHz Sempron laptop it keeps up with me, but if I just turn on the
power management (cutting the clock speed in half), it lags behind.  A lot
of my customers run old P3 computers.  I would have egg on my face.  :-/

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com 

Some of you already know, but just to be sure, Sam is offline through August.
So, lack of response should not be taken as unresponsiveness.

Thanks
Bruce

I had experimented with Pollock from Dec 2004 to Feb 2005. It looked
interesting and I submitted some fixes. But it was by no means
finished at that time. It was both enticing in its approach but
incredibly frustrating at the time.

I started working with the latest version in the last two weeks and I
have found it overall to be much more complete and stable. It is
obvious that a lot of work has been accomplished in the last year and
a half.

Performance does need to be fixed.

Reg

Hi steven

I do not consider your email as a rant!
I was watching the Pollock story and I got two thoughts:
        - how can we design a framework without real applications built with  
it? (at least Ralph patterns said "three
        applications first"

        - how pollock will enable the new widgetery that is coming (and is  
certainly
        the death of widget emulation) and fairly different on each platform.

I have the impression that Pollock may be a nice try but too late.

Steven Kelly wrote:
[..]

> I still have high hopes for Pollock: doing it is the right decision, and
> Sames is doing it according to good XP practice (although it remains to
> be seen how well his interpretation of some aspects like late
> optimization works in the end; certainly it's been bad news so far in
> that it's stopped much early adoption).
>

Hmm, according to XP one would release often and produce software
valuable to the customer in each release. After 4 years of developing
Pollock, according to what I read, this does not seem to be the case. So
this maybe is a problem of not having the right user stories and/or
wrong priorities for the user stories. Maybe there is a real customer
missing (or his voice is not heard)?

Cheers,
        Hubert

I share the same feelings. Pollock looks great at what it is trying to
do, but does it really solve all GUI problems? Just look at the new
look and feel of Vista, the Office "Ribbon", etc. I think emulating
all widgets will become increasingly harder, as operating systems
starts using more advanced visual effects on their "native" widgets.

Let's say a designer decides that, "(…) given all the new optimized
hardware, let's make all widgets slightly reflect nearby widgets and
the mouse cursor." A nonsense change, but something that would be very
hard to emulate in Smalltalk.

Note that Cincom also see a problem in supporting only emulated
widgets, and there are plans to mix emulated and "native" widgets
after Pollock is finished. I think this path makes perfect sense. This
is what SWT (Eclipse) has been doing for years. The sad part of this
is the long time it seems to finish these projects.

The support for making visual impressive application using VisualWorks
needs to be improved at all layers:
- Pollock needs to be finished
- Work on mixing "native" and emulated widgets needs to be started.
- We need better support for doing fast 2D graphics in the Virtual
Machine. Image copying, alpha blending, anti-aliased drawing, etc.
should be fully supported.

Runar

And integrate or wrap wpf (Windows presentation foundation in .net3) API (for Windows)...
Janos

-----Original Message-----
From: Runar Jordahl [mailto:[hidden email]]
Sent: Wednesday, August 02, 2006 12:03 PM
To: stéphane ducasse
Cc: Steven Kelly; VW NC
Subject: Re: Pollock rant

I share the same feelings. Pollock looks great at what it is trying to do, but does it really solve all GUI problems? Just look at the new look and feel of Vista, the Office "Ribbon", etc. I think emulating all widgets will become increasingly harder, as operating systems starts using more advanced visual effects on their "native" widgets.

Let's say a designer decides that, "(...) given all the new optimized hardware, let's make all widgets slightly reflect nearby widgets and the mouse cursor." A nonsense change, but something that would be very hard to emulate in Smalltalk.

Note that Cincom also see a problem in supporting only emulated widgets, and there are plans to mix emulated and "native" widgets after Pollock is finished. I think this path makes perfect sense. This is what SWT (Eclipse) has been doing for years. The sad part of this is the long time it seems to finish these projects.

The support for making visual impressive application using VisualWorks needs to be improved at all layers:
- Pollock needs to be finished
- Work on mixing "native" and emulated widgets needs to be started.
- We need better support for doing fast 2D graphics in the Virtual
Machine. Image copying, alpha blending, anti-aliased drawing, etc.
should be fully supported.

Runar

I'd rather see an Objective-C bridge on the Mac.

On Aug 2, 2006, at 3:50 AM, Kazsoki, Janos wrote:

From: Runar Jordahl [mailto:[hidden email]]
> The support for making visual impressive application using VisualWorks
> needs to be improved at all layers:
> - Pollock needs to be finished
> - Work on mixing "native" and emulated widgets needs to be
started.
> - We need better support for doing fast 2D graphics in the Virtual
> Machine. Image copying, alpha blending, anti-aliased drawing, etc.
> should be fully supported.

A big "yes" to that last one! That is an area where we users are pretty
much powerless to correct something that makes VW look seriously out of
date. Doing any of these in Smalltalk is too slow, so we as Smalltalk
users are stuck. Java has had these since 1998 - 8 years now! How far do
you want to lag behind?

If you don't have the manpower or skill (you probably don't), but Cincom
Smalltalk is profitable (it is), why not do what Java did, and simply
license existing anti-aliasing and alpha technology? Sun signed the
agreement with Ductus in February 98, and Java2D was released before in
August 98:

http://www.ductus.com/docs/PressRelease_Java.html
http://www.javaworld.com/javaworld/jw-08-1998/jw-08-media.html

Steve

Regarding the future directions of VW and its GUI, I have some strong
concerns:

Wrapper should never be moved to "obsolete" at all. Although we all know
it's not perfect, huge investements have been made in products based on
it. Most of them probably won't benefit from a port to Pollock (if it's
running, why change it?). In contrary, this would rather impose
additional expenses and hassle on the customers.

I definitely can't port my products, because that would throw my shop
into expensive chaos for months and I simply can't afford that. My
company is selling shrink-wrapped products. We can't charge our
customers for such kind of maintenance. If Pollock will become
mandatory, I will port the products -- to something other than VW.

I strongly request that Wrapper receives a lifetime support to the
extent that it will always be loadable and functional in its last
official state to protect existing investments. This should not require
too much effort for each new VW release (a little tweak here and there).

Moreover, Pollock and Wrapper should both be loadable into a neutral
base image alternatively, so a Wrapper application won't  be stuffed
with redundant Pollock code and vice versa.

Regarding GUI performance, VW should not rely on current 3GHhz/2GB
hardware as an excuse for sluggish or "academic" design (although it
might be tempting to overdo it due to the comfortable performance of the
IDE). The VisualWorks OE is a fantastic masterpiece of engineering
(kudos to Eliot et al), by far fast enough even on slowest hardware.
There is no reason to waste this great asset! The opposite is true:
Cincom should take the current hardware as a chance to make VW appear
even faster than ever.

I am deliberately doing GUI optimizations on a slow 600MHz machine, so I
can spot all the redundant refreshes, flicker and double displays with
the naked eye. This proved to be a very successful strategy. Sam might
want to do it the same way. One only optimizes, if it really hurts.

Regarding speed, "immediately" is the goal. It is definitely possible.
It's 2006 - not 1984.

Andre

Steven Kelly wrote:
I absolutely agree:

We are now stuck because ellipses and rounded rectangles look horribly
on Windows (and Windows only!). We tracked down the problem and it is
definitely inside VM (primitives 990 and 991) and not in Windows GDI,
because with dllcc we can draw them correctly. The problem with this
'fix' is that we can draw *only* to windows (graphics medium) and not
to pixmaps. This is because there is no way how to retrieve pixmap
handle on Smalltalk level.

This is currently our pain in the...

If I am correct, this particular bug is there for years and everybody
knows it's there and to fix it is a matter of days for a man with VM
knowledge. This is just weird... :-(((

Ladislav Lenart

Ladislav Lenart wrote:

And don't forget the Line drawing sorry state.  While Windows supports
number of different line styles natively - VW just ignores them, despite
the fact that the line drawing methods have attribute "style" in them

> If I am correct, this particular bug is there for years and everybody
> knows it's there and to fix it is a matter of days for a man with VM
> knowledge. This is just weird... :-(((
>
> Ladislav Lenart
>
>
>