[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] GTK graphics status
|
> Creating an Object is very costly.
Do you have numbers to back this up? Is your 50% number measured? I have
been burned by this assumption before, going back to Smalltalk days.
I didn't mean to black-or-white the issue on SWT implementation, by the
way, just offer another perspective
-Andrew
"Randy Hudson" <hudsonr@xxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
03/21/2002 10:12 AM
Please respond to platform-swt-dev
To: platform-swt-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-swt-dev] GTK graphics status
Are you implementing SWT on Photon?
Ok. I'm wrong about looping over 1,000,000 bytes. Java is probably just
as quick as C in such tasks.
So let's take a concrete example from org.eclipse.swt.graphics.GC:
public Point textExtent(String string, int flags) {
if (handle == 0) SWT.error(SWT.ERROR_GRAPHIC_DISPOSED);
if (string == null) SWT.error (SWT.ERROR_NULL_ARGUMENT);
if (string.length () == 0) {
SIZE size = new SIZE();
// OS.GetTextExtentPoint32(handle, SPACE, SPACE.length(), size);
OS.GetTextExtentPoint32W(handle, new char [] {' '}, 1, size);
return new Point(0, size.cy);
}
RECT rect = new RECT();
TCHAR buffer = new TCHAR(getCodePage(), string, false);
int uFormat = OS.DT_LEFT | OS.DT_CALCRECT;
if ((flags & SWT.DRAW_DELIMITER) == 0) uFormat |= OS.DT_SINGLELINE;
if ((flags & SWT.DRAW_TAB) != 0) uFormat |= OS.DT_EXPANDTABS;
if ((flags & SWT.DRAW_MNEMONIC) == 0) uFormat |= OS.DT_NOPREFIX;
OS.DrawText(handle, buffer, buffer.length(), rect, uFormat);
return new Point(rect.right, rect.bottom);
}
For a client calling gc.textExtent("foo"), SWT creates lots of new Objects
(5, I believe) that are never available to the client. Creating an Object
is very costly. As a result, 50% of the time spent in gc.textExtent() is
consumed in newing Objects, and about 40% of the time spent in the OS
natives. An HTML editor written in SWT calls this method thousands of
times whenever the user resizes or types a character. Currenlty, over
half
of the objects created when re-flowing text are created in SWT.
So, writing code whose performance can be measured with a java profiler is
part of the reason that the code doesn't perform at its best.
As Steve pointed out, we could all write Natives, but then our code
wouldn't be cross-platform.
|---------+---------------------------------->
| | Andrew_Sandstrom@xxxxxx|
| | m |
| | Sent by: |
| | platform-swt-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 03/20/2002 04:28 PM |
| | Please respond to |
| | platform-swt-dev |
| | |
|---------+---------------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-swt-dev@xxxxxxxxxxx |
| cc: platform-swt-dev@xxxxxxxxxxx |
| Subject: Re: [platform-swt-dev] GTK graphics status |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
What was the original point anyway? Was it about the SWT wrappering single
API calls to the OS vs bundling a wad of native code?
If so, then I could add one additional point about this beyond debugging.
This feature of SWT is very nice for performance analysis, especiallly
with
J9 MicroAnalyzer and Smartlinker Profiler. Since there is a one-to-one
mapping between an SWT native method and an OS call, I can use
MicroAnalyzer and Smartlinker profiler to get timing information on not
just java code, but OS calls. This has proven to be a lifesaver in some
situations. I used this to find a whopping performance bug on Photon. If
this was buried somewhere in a wad of C code I'm not sure I would have
found it.
-Andrew
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
