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

["Chris McKillop" <cdm@xxxxxxx>]

Yes - that was the other thing I was going to look at.  If when I am doing
my tests I see something odd (for example, I have noticed already that
setFont() seems to be called an insane number of times) I will try to trace
it back into the generic code.  Already fixing a bug in in org.eclipse.ui
that I traced back into while thinking I was going to have to fix something
in SWT. ;)

    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: "Steve Northover" <Steve_Northover@xxxxxxx>
To: <platform-swt-dev@xxxxxxxxxxx>
Sent: Tuesday, September 10, 2002 10:43 AM
Subject: Re: [platform-swt-dev] Re: SWT and Photon


>
> Let me add, if an API is called a ludicrous amount of times, fixing this
in
> the caller results in performance improvements on all platforms.
>
>
>
>
>                       "Mike Wilson"
>                       <Mike_Wilson@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 10:10 AM
>                       Please respond to
>                       platform-swt-dev
>
>
>
>
>
>
> 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>
>                                           To:
>    Sent by:                       <platform-swt-dev@xxxxxxxxxxx>
>    platform-swt-dev-admin@eclipse         cc:
>    .org                                   Subject:        Re:
>                                   [platform-swt-dev] Re: SWT and Photon
>
>    09/09/2002 07:42 PM
>    Please respond to
>    platform-swt-dev
>
>
>
>
>
> >
>
> > 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
>