JOGL preload
in [Java Help]
|
Prev: How to find out from *.class file with which Java version 1.6 or 1.5 it was compiled?
Next: Creating a big file
From: Daniel Pitts on 5 Aug 2010 14:56 On 8/4/2010 4:51 PM, Gene wrote: > On Aug 4, 6:39 pm, Olaf Klischat<olaf.klisc...(a)googlemail.com> wrote: >> On 08/04/2010 06:01 PM, Gene wrote: >> >>> We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app. >>> The JOGL part of the system draws on a GLCanvas that's on an initially >>> hidden tab control. The normal pattern of use is to work in the Swing- >>> only part of the system and then select the GLCanvas tab to visualize >>> work so for. >> >>> When the user selects the GLCanvas tab, there is a delay of 2 to 20 >>> seconds while the disk clatters and all window activity freezes. >> >> That doesn't sound normal. And why the large variance (2 to 20 seconds)? >> >>> Then >>> all is perfect. Afterward switching among tabs is instantaneous. >> >>> So it looks like it's binding dynamic libraries upon the first tab >>> click when the GLCanvas is first made visible. >> >> Have you verified this? Try running the program in a profiler like >> jvisualvm and maybe in a syscall tracer to see where the time is spent. >> The system shouldn't spend two, let alone twenty, seconds linking in >> some OpenGL libraries. Are you sure it's not large textures or other GL >> data being loaded initially from the filesystem? Does the delay still >> occur if you have empty initialization and display methods in the GLCanvas? > > Thanks for the insight. I tried profiling in the Netbeans > environment. Nothing in the output indicated where the time went. > I'll look at the profilers you suggest. > > The 20 seconds is on a lame, old machine with the disk deliberately > nearly full for a stress test with low swap space. The 2 seconds is > much more typical. This app has to run on computers in elementary > schools that tend to be old and slow. Hence the testing regime. > > There are textures, but nearly all are tiny. The exception is a sky > map, which is ~ 1/2 megabyte in JPEG form. > > Even if it is something like textures loading, the question seems > roughly the same. Textures are loaded (and reloaded) in the init() > method. Is there a way to force the GL context (including textures) > to be initialized before the first paint event causes it to happen? Sounds like you might need to tune your JVM memory settings. There are plenty of good documents available, I'll let you google for it yourself. My thought is that maybe your program is allocating enough objects/memory, fast enough that the JVM has to resize its heap(s) several times. If you can set your initial heap size to just over the peak start-up heap size, you might see start-up time improvements. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Gene on 5 Aug 2010 21:41 On Aug 5, 2:56 pm, Daniel Pitts <newsgroup.spamfil...(a)virtualinfinity.net> wrote: > On 8/4/2010 4:51 PM, Gene wrote: > > > > > On Aug 4, 6:39 pm, Olaf Klischat<olaf.klisc...(a)googlemail.com> wrote: > >> On 08/04/2010 06:01 PM, Gene wrote: > > >>> We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app. > >>> The JOGL part of the system draws on a GLCanvas that's on an initially > >>> hidden tab control. The normal pattern of use is to work in the Swing- > >>> only part of the system and then select the GLCanvas tab to visualize > >>> work so for. > > >>> When the user selects the GLCanvas tab, there is a delay of 2 to 20 > >>> seconds while the disk clatters and all window activity freezes. > > >> That doesn't sound normal. And why the large variance (2 to 20 seconds)? > > >>> Then > >>> all is perfect. Afterward switching among tabs is instantaneous. > > >>> So it looks like it's binding dynamic libraries upon the first tab > >>> click when the GLCanvas is first made visible. > > >> Have you verified this? Try running the program in a profiler like > >> jvisualvm and maybe in a syscall tracer to see where the time is spent.. > >> The system shouldn't spend two, let alone twenty, seconds linking in > >> some OpenGL libraries. Are you sure it's not large textures or other GL > >> data being loaded initially from the filesystem? Does the delay still > >> occur if you have empty initialization and display methods in the GLCanvas? > > > Thanks for the insight. I tried profiling in the Netbeans > > environment. Nothing in the output indicated where the time went. > > I'll look at the profilers you suggest. > > > The 20 seconds is on a lame, old machine with the disk deliberately > > nearly full for a stress test with low swap space. The 2 seconds is > > much more typical. This app has to run on computers in elementary > > schools that tend to be old and slow. Hence the testing regime. > > > There are textures, but nearly all are tiny. The exception is a sky > > map, which is ~ 1/2 megabyte in JPEG form. > > > Even if it is something like textures loading, the question seems > > roughly the same. Textures are loaded (and reloaded) in the init() > > method. Is there a way to force the GL context (including textures) > > to be initialized before the first paint event causes it to happen? > > Sounds like you might need to tune your JVM memory settings. > There are plenty of good documents available, I'll let you google for it > yourself. > > My thought is that maybe your program is allocating enough > objects/memory, fast enough that the JVM has to resize its heap(s) > several times. If you can set your initial heap size to just over the > peak start-up heap size, you might see start-up time improvements. > > -- > Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> Great point. This is my first serious Java project, so I'm not used to tuning GC. Thanks very much.
From: Gene on 12 Aug 2010 21:11 On Aug 5, 2:56 pm, Daniel Pitts <newsgroup.spamfil...(a)virtualinfinity.net> wrote: > On 8/4/2010 4:51 PM, Gene wrote: > > > > > On Aug 4, 6:39 pm, Olaf Klischat<olaf.klisc...(a)googlemail.com> wrote: > >> On 08/04/2010 06:01 PM, Gene wrote: > > >>> We have a medium-sized (abuot 40,000 SLOC) Swing Desktop+JOGL app. > >>> The JOGL part of the system draws on a GLCanvas that's on an initially > >>> hidden tab control. The normal pattern of use is to work in the Swing- > >>> only part of the system and then select the GLCanvas tab to visualize > >>> work so for. > > >>> When the user selects the GLCanvas tab, there is a delay of 2 to 20 > >>> seconds while the disk clatters and all window activity freezes. > > >> That doesn't sound normal. And why the large variance (2 to 20 seconds)? > > >>> Then > >>> all is perfect. Afterward switching among tabs is instantaneous. > > >>> So it looks like it's binding dynamic libraries upon the first tab > >>> click when the GLCanvas is first made visible. > > >> Have you verified this? Try running the program in a profiler like > >> jvisualvm and maybe in a syscall tracer to see where the time is spent.. > >> The system shouldn't spend two, let alone twenty, seconds linking in > >> some OpenGL libraries. Are you sure it's not large textures or other GL > >> data being loaded initially from the filesystem? Does the delay still > >> occur if you have empty initialization and display methods in the GLCanvas? > > > Thanks for the insight. I tried profiling in the Netbeans > > environment. Nothing in the output indicated where the time went. > > I'll look at the profilers you suggest. > > > The 20 seconds is on a lame, old machine with the disk deliberately > > nearly full for a stress test with low swap space. The 2 seconds is > > much more typical. This app has to run on computers in elementary > > schools that tend to be old and slow. Hence the testing regime. > > > There are textures, but nearly all are tiny. The exception is a sky > > map, which is ~ 1/2 megabyte in JPEG form. > > > Even if it is something like textures loading, the question seems > > roughly the same. Textures are loaded (and reloaded) in the init() > > method. Is there a way to force the GL context (including textures) > > to be initialized before the first paint event causes it to happen? > > Sounds like you might need to tune your JVM memory settings. > There are plenty of good documents available, I'll let you google for it > yourself. > > My thought is that maybe your program is allocating enough > objects/memory, fast enough that the JVM has to resize its heap(s) > several times. If you can set your initial heap size to just over the > peak start-up heap size, you might see start-up time improvements. > > -- > Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> Thanks again. Increasing the initial heap size helped a lot.
From: Daniel Pitts on 13 Aug 2010 20:13
On 8/12/2010 6:11 PM, Gene wrote: > On Aug 5, 2:56 pm, Daniel Pitts > <newsgroup.spamfil...(a)virtualinfinity.net> wrote: >> Sounds like you might need to tune your JVM memory settings. >> There are plenty of good documents available, I'll let you google for it >> yourself. >> >> My thought is that maybe your program is allocating enough >> objects/memory, fast enough that the JVM has to resize its heap(s) >> several times. If you can set your initial heap size to just over the >> peak start-up heap size, you might see start-up time improvements. >> > Thanks again. Increasing the initial heap size helped a lot. > Glad to hear it. Thanks for the follow up. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> |