Re: [platform-swt-dev] Re: SWT and Photon

["Chris McKillop" <cdm@xxxxxxx>]

We shall see.  I am studying the other bindings and, for the most part, you
are using things like the win32 API in the same way that an application
written in C would use the win32 API.  This is not the case with the photon
bindings and is the only reason I can see that would account for the
difference in speed (ie: comparing win32 eclipse to a native app and
comparing photon eclipse to a native app).  Photon Eclipse (UI speed wise)
is a lot slower then a native application so the SWT must be doing something
wrong.  A normal photon app never calls malloc/memmove/free to interact with
Photon and so this makes it a prime "finger pointer".

Let the testing being!

    chris

--
  Chris McKillop <cdm@xxxxxxx>     "The faster I go, the behinder I get."
  Software Engineer, QNX                    -- Lewis Carroll --
  http://qnx.wox.org/



----- Original Message -----
From: "Mike Wilson" <Mike_Wilson@xxxxxxx>
To: <platform-swt-dev@xxxxxxxxxxx>
Sent: Tuesday, September 10, 2002 7:10 AM
Subject: Re: [platform-swt-dev] Re: SWT and Photon


> A ten percent change at the microscopic level is *guaranteed* not to be
> noticeable in the feel of Eclipse. You need to be shooting for at least
> double the performance unless it's an API which is called a ludicrous
> number of times. Even then, performance in the natives really is almost
> never the bottleneck. That's why we are so adamant about the need for
> benchmarks.
>
> McQ.
>
>
>
>
>
> "Chris McKillop" <cdm@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 09/09/2002 07:42 PM
> Please respond to platform-swt-dev
>
>
>         To:     <platform-swt-dev@xxxxxxxxxxx>
>         cc:
>         Subject:        Re: [platform-swt-dev] Re: SWT and Photon
>
> >
>
> > I'm going to apologize up front for posting this message to the
> > platform-swt-dev mailing list without asking you first. The comments you
> > were making are *exactly* the kind of discussion I would like to see
> > happening on the mailing list, so I'm going to use this message as a
> > seed...
> >
>
> Love to use the list - no worries at all. :)
>
> >
> > What you say below about the "Photon style guide" reminded me of one of
> > the places where you have to watch out for "the bigger picture":
> >   - there are some places in the eclipse UI where code was made to work
> a
> > particular way because we were trying to behave like the platform,
> >   - and there are other places where the _eclipse_team's_ UI design
> people
> > specified a particular appearance,
> >   - and there are other places where some of the text of the UI was
> > mandated by the legal people to have a certain look&feel (like the About
> > dialog),
> >   - and there are other places where the swt team made it work a certain
> > way just 'cause it seemed like a good idea. :-)
> >  When each of these cases is occurring is not always obvious.
> >
>
> Yep - and I am not really doing anything drastic.  In fact, I have
> examples
> online of the differences in the chnages I am doing:
>
> http://qnx.wox.org/swt/
>
> Please - anyone and everyone comment.  Thus far it has primarily been
> picking which fonts are being used and how the Group widget is created.
> The
> changes are somtimes subtle, so it is best to have both the before and the
> after shots side-by-side.
>
>
> >
> > As to the rest of what you've said, one of the fundamental design
> > philosophies of SWT is _no_custom_C_code_. When you talk about adding
> new
> > JNI methods below, I got *very* nervous. At the very least, before you
> go
> > down that path, you need to provide us with compelling benchmark
> > information which shows that writing C code equivalents of some of the
> > existing methods will be a *significant* performance win. That's both at
> > the microscopic and the macroscopic (i.e. eclipse runs significantly
> > better) level. Just so you know, our experience on other platforms has
> > been that, writing C code for performance tuning purposes frequently
> > provides very little real-world benefit versus the equivalent
> JIT-compiled
> > java code.
> >
>
> See, I am not trying to change things algorithmically.  I totally agree,
> doing the algorithims in java vs. C will not be a huge difference in
> speed.
> But, if I can remove expensive system calls that don't need to be made
> when
> the function is written in C, there will be a big BIG win (thinking
> malloc,
> memmove, free).  So, where does one draw the performance increase lines?
> ;)
> It is very hard to measure the performance under Eclipse (macroscopic) so
> that will have to be a "feel" issue.  As for the microscopic - Would a 10%
> increase in speed justify the change?  More?  Less?
>
> Just so you know, I will be doing my test cases on a P166 - both macro and
> micro.  This way speed changes will be more prononouced.  And it is also
> more indicative of the class of processors QNX and OTI's customers are
> using
> today with Photon.
>
>     chris
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>