Re: JVM 1.6 is fast
- From: Roedy Green <my_email_is_posted_on_my_website@xxxxxxxxxxxxxx>
- Date: Sat, 28 Jan 2006 22:33:21 GMT
On Sat, 28 Jan 2006 16:01:49 +0100, "Jeroen Wenting" <jwenting at
hornet dot demon dot nl> wrote, quoted or indirectly quoted someone
who said :
>You could test that by running it on a terminal to a machine that has a
>text-only user interface. That should just cause the character number to get
>sent to the terminal by the OS and rendered in hardware without tasking the
>processor.
you can test it by > null or >file.txt or even just minimising the
output window.
In DOS days you had a 80x25 array of chars each with an attribute
byte. You could control what was on the screen by poking this "regen
buffer". It was just an array of bytes at a magic location in RAM.
Display was incredibly quick this way in Abundance (my home brew
language).. However when DOS programs are emulated in Windows, The
penalty box has to periodically compare the contents of the regen
buffer with the last sweep and regenerate the bit maps for the chars
that have changed.
In the DOS days, the usual VGA hardware had no provision for
scrolling. To scroll, you copied everything up a slot.
In emulation, if you go about it is a flat footed way, you end up
regenerating the characters for every line on every scroll, rather
than using a bitblt, or some clever scrolling hardware in the graphics
hardware.
All this background brings us to the problem of Java console i/o. It
has inherited a DOS-compatible console.
It is not simply a problem of displaying chars in a scrolling window.
Java knows how to do that quite efficiently. Chars sent to the console
need to go to the command processor for pipe redirection. So I think
this means Java can't do the rendering.
With its arms tied, what can Java do?
It could buffer chars then hand them over in a burst. every tenth of
a second or so. That might reduce the amount of re-rendering the
entire screen. You might experiment with variable delay -- one for
dribbling chars and one for a torrent. I'm not sure just how clever
the cmd.exe and 4NT.exe processors are about rendering and scrolling
the console. Are they using REGEN emulation, or are they scrolling
just like any native windows app?
The point is Jet is having a lot more trouble with console I/O that
HotSpot is,so there must be something you can do. Further even
Hotspot is taking 2 seconds or so to output 4000 characters. This is
still ridiculously slow.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
.
- References:
- JVM 1.6 is fast
- From: Roedy Green
- Re: JVM 1.6 is fast
- From: Roedy Green
- Re: JVM 1.6 is fast
- From: Oliver Wong
- Re: JVM 1.6 is fast
- From: Roedy Green
- Re: JVM 1.6 is fast
- From: Jeroen Wenting
- JVM 1.6 is fast
- Prev by Date: Re: The Writhing fern and other idiotic progress bars
- Next by Date: Re: WHY DOSE JAVA HAVE TO BE SO WORDY
- Previous by thread: Re: JVM 1.6 is fast
- Next by thread: WHY DOSE JAVA HAVE TO BE SO WORDY
- Index(es):
Relevant Pages
|