[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Re: SWT and Photon
|
The other obvious thing that comes to mind is that the Windows native
widget implemenation and graphics drivers may be faster than other
platforms ... no flames please.
"Chris McKillop"
<cdm@xxxxxxx> To: <platform-swt-dev@xxxxxxxxxxx>
Sent by: cc:
platform-swt-dev-admin@ Subject: Re: [platform-swt-dev] Re: SWT and Photon
eclipse.org
09/10/02 02:49 PM
Please respond to
platform-swt-dev
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
>
>
>
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
