This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] enable double buffering on GtkCanvasPeer


Mark Wielaard <mark@klomp.org> writes:

> Hi,
> 
> On Sat, 2003-07-19 at 02:28, graydon hoare wrote:
> > Tom Tromey <tromey@redhat.com> writes:
> > > >>>>> "graydon" == graydon hoare <graydon@redhat.com> writes:
> > > 
> > > graydon> if JNI is really super-expensive
> > > 
> > > JNI is pretty heavy.  BTW I like your numbers-driven approach.
> > 
> > drumroll please...
> > [...]
> > I'm convinced. rewriting everything to use as little JNI as possible.
> 
> Good to see these numbers. We actually have some (admittedly old and not
> updated for at least three years I am afraid) documentation about native
> efficiency:
> http://www.gnu.org/software/classpath/docs/hacking.html#SEC11
> Probably nothing you not know already by now though.

wait, wait, hold the phone.

I realized shortly after the first post that my comparison was apples
to oranges; I was dropping 2/3 of the rectangles on the floor due to a
stupid error. the correct numbers appear to be more like this:

1 JNI per Xr call:

draw speed: 561.797 rects / second
draw speed: 452.693 rects / second
draw speed: 476.644 rects / second
draw speed: 464.900 rects / second
draw speed: 689.179 rects / second
draw speed: 484.966 rects / second
draw speed: 399.520 rects / second
draw speed: 475.963 rects / second
draw speed: 603.136 rects / second

1 JNI per Graphics2D call:

draw speed: 650.195 rects / second
draw speed: 493.583 rects / second
draw speed: 647.249 rects / second
draw speed: 437.636 rects / second
draw speed: 460.193 rects / second
draw speed: 449.236 rects / second
draw speed: 551.571 rects / second

In other words, it appears that batching JNI calls doesn't buy me a
great deal in thie context, perhaps 25 or so rectangles / second
improvement (~ 5% ?). considering that it's more complex and harder to
debug (adds an extra layer of re-encoding / decoding for drawing
calls) I'd prefer to avoid it for the time being. maybe I'll get some
more convincing numbers later.

-graydon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]