DrJava

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

I can't claim credit for the implementation, just for part of the
maintenance.

I stand corrected. It's amazing what one can learn for the implementor of
a subsystem.

When DrJava is not in debug mode, the debugger is not active and there is
no slowdown that can be attributed to DrJava's debugging features.
Execution within DrJava is slower because 1) the user program runs in a
separate Java virtual machine (JVM) and needs to communicate with DrJava's
JVM to do console I/O, and 2) the cost of doing console I/O in a graphical
environment such as DrJava is higher than in a text environment found in a
pure console.

To illustrate why 1) may be particularly costly, it may be worthwhile to
explain how the communication may be implemented. Depending on the
operating system, it may be as cheap as copying blocks of memory within
your RAM, or as expensive as sending the information through a networking
card using your IP address.

We are working hard to make DrJava as fast and easy to use as possible.
But all benefits come at a cost, and DrJava is no exception. I hope being
aware of these costs help. I mainly wanted to respond to the incorrect
statement that the debugger was causing the slowdown, though.

Set to pending. This ticket will close in two weeks. If you think that
this issue has not been resolved, log in and post a comment here.

DrJava has to add hooks into your program so that the debugger can
function. Although you may not be actively debugging, the debugger is still
active in order to allow you to debug unexpected exceptions.

Logged In: NO

The problem seems to be the overzealous creation of Scanner objects in my
code. When i streamlined it, it ran a lot faster in DrJava. But even with
all the Scanners, it ran fast outside DrJava, so what is DrJava doing
differently?