"Warm-out" times

( Warm-up times was supposed to be the title... )

Am 16.05.2010 um 18:26 schrieb Sciss:

> hey....
>
> using scala in realtime applications : i am a bit concerned about the warm-out times that scala (or probably the JVM) exhibits about first-usage of classes. e.g. i just tested my audio file class, and opening a file takes 300 ms from cold start, 1 ms from warm start. same for ugen-graph-creation with my scala collider project.
>
> is anyone aware of some tools for the JVM that i can use to deliberately "pre-load" a class or a tree of related classes (e.g. everything in one particular package), so that you can "warm-up" the system for time critical classes? are there any VM options to look at?
>
> best, -sciss-
>

On 05/16/2010 06:26 PM, Sciss wrote:
> hey....
>
> using scala in realtime applications : i am a bit concerned about the warm-out times that scala (or probably the JVM) exhibits about first-usage of classes. e.g. i just tested my audio file class, and opening a file takes 300 ms from cold start, 1 ms from warm start. same for ugen-graph-creation with my scala collider project.
>
> is anyone aware of some tools for the JVM that i can use to deliberately "pre-load" a class or a tree of related classes (e.g. everything in one particular package), so that you can "warm-up" the system for time critical classes? are there any VM options to look at?
>
> best, -sciss-
>
>

This is a pretty common problem with, for example, Lucene-based
applications.

If it's a problem, you just have to write "warm-up code" that warms up
the jvm for the parts that matter. It's more art than science.

cheers,
Eric

how would i warm up the classes without instantiation? do i just do classLoader.load( className ), for Class.forName(), or...? do you do something like that in lucene? i would think of this:

def preload( p: java.lang.Package ) { ... }

how do i find out all the classes in the package?

best, -sciss-

Am 17.05.2010 um 16:24 schrieb Eric Bowman:

> On 05/16/2010 06:26 PM, Sciss wrote:
>> hey....
>>
>> using scala in realtime applications : i am a bit concerned about the warm-out times that scala (or probably the JVM) exhibits about first-usage of classes. e.g. i just tested my audio file class, and opening a file takes 300 ms from cold start, 1 ms from warm start. same for ugen-graph-creation with my scala collider project.
>>
>> is anyone aware of some tools for the JVM that i can use to deliberately "pre-load" a class or a tree of related classes (e.g. everything in one particular package), so that you can "warm-up" the system for time critical classes? are there any VM options to look at?
>>
>> best, -sciss-
>>
>>
>
> This is a pretty common problem with, for example, Lucene-based
> applications.
>
> If it's a problem, you just have to write "warm-up code" that warms up
> the jvm for the parts that matter. It's more art than science.
>
> cheers,
> Eric
>

If you are sure your problem is class loading times, and not the JIT for
example (you could check that with -XX:+PrintCompilation), couldn't you
just run your hot paths with dummy data once?

Cheers,
Ingo

On 5/17/10 5:24 PM, Eric Bowman wrote:
> On 05/16/2010 06:26 PM, Sciss wrote:
>> hey....
>>
>> using scala in realtime applications : i am a bit concerned about the warm-out times that scala (or probably the JVM) exhibits about first-usage of classes. e.g. i just tested my audio file class, and opening a file takes 300 ms from cold start, 1 ms from warm start. same for ugen-graph-creation with my scala collider project.
>>
>> is anyone aware of some tools for the JVM that i can use to deliberately "pre-load" a class or a tree of related classes (e.g. everything in one particular package), so that you can "warm-up" the system for time critical classes? are there any VM options to look at?
>>
>> best, -sciss-
>>
>>
>
> This is a pretty common problem with, for example, Lucene-based
> applications.
>
> If it's a problem, you just have to write "warm-up code" that warms up
> the jvm for the parts that matter. It's more art than science.
>
> cheers,
> Eric
>

it basically works by referencing the classes. e.g.

scala> val classes = List( classOf[ AudioFile ], impl.AIFFHeader.getClass, classOf[ BufferHandler ], classOf[ java.io.File ], classOf[ java.nio.channels.Channels ], classOf[ java.io.RandomAccessFile ], classOf[ java.nio.ByteBuffer ], classOf[ AudioFileType ], classOf[ AudioFileSpec ], classOf[ SampleFormat ], classOf[ BufferBidi ], classOf[ AudioFileHeader ], classOf[ java.io.IOException ], classOf[ java.io.DataInputStream ], classOf[ java.io.FileInputStream ], classOf[ java.io.BufferedInputStream ], classOf[ java.io.DataInput ])

scala> def tim = System.currentTimeMillis

scala> val t1 = tim; val af = AudioFile.openRead( "/Users/rutz/Desktop/Interface3/audio_work/SteineKlopf-L.aif" ); val t2 = tim; af.close

t2-t1 // --> 97 ms

before i had 300 ms, so i will need to find a systematic way to determine all classes involved in one particular package. because re-running:

scala> val t1 = tim; val af = AudioFile.openRead( "/Users/rutz/Desktop/Interface3/audio_work/SteineKlopf-L.aif" ); val t2 = tim; af.close

t2-t1 // --> 1 ms !!! that's what i want

i don't know how this is possible...? obviously what i cannot do is instantiate classes or call methods on objects, as the warm up needs to be completely transparent

maybe something like proguard could be exploited? how does the scala REPL tab-completion determine the classes which are in scope (imported)?

best, -sciss-

Am 17.05.2010 um 17:00 schrieb Ingo Maier:

> If you are sure your problem is class loading times, and not the JIT for example (you could check that with -XX:+PrintCompilation), couldn't you just run your hot paths with dummy data once?
>
> Cheers,
> Ingo
>
> On 5/17/10 5:24 PM, Eric Bowman wrote:
>> On 05/16/2010 06:26 PM, Sciss wrote:
>>> hey....
>>>
>>> using scala in realtime applications : i am a bit concerned about the warm-out times that scala (or probably the JVM) exhibits about first-usage of classes. e.g. i just tested my audio file class, and opening a file takes 300 ms from cold start, 1 ms from warm start. same for ugen-graph-creation with my scala collider project.
>>>
>>> is anyone aware of some tools for the JVM that i can use to deliberately "pre-load" a class or a tree of related classes (e.g. everything in one particular package), so that you can "warm-up" the system for time critical classes? are there any VM options to look at?
>>>
>>> best, -sciss-
>>>
>>>
>>
>> This is a pretty common problem with, for example, Lucene-based
>> applications.
>>
>> If it's a problem, you just have to write "warm-up code" that warms up
>> the jvm for the parts that matter. It's more art than science.
>>
>> cheers,
>> Eric
>>
>

wow, lot's of stuff going on there.... although it doesn't look like that is the main problem, i will need to investigate further there...

Am 17.05.2010 um 17:00 schrieb Ingo Maier:

> -XX:+PrintCompilation

ok, times are less dramatic if i run the code as application, not in the REPL. e.g.

196 java.lang.ThreadLocal$ThreadLocalMap::set (136 bytes)
197 ! sun.jkernel.DownloadManager::getBootClassPathEntryForResource (179 bytes)
198 sun.jkernel.DownloadManager::getBootClassPathEntryForClass (30 bytes)
AudioFileSpec(AIFF,Float,1,44100.0,11949760)
time : 82
AudioFileSpec(AIFF,Float,1,44100.0,11949760)
time : 1

so JIT seems a minor problem, and part of 82 ms might be due to native IO buffering. still if i could reduce the first run to 10% (say 8 ms) that would be great.

best, -sciss-

Am 17.05.2010 um 17:18 schrieb Sciss:

> wow, lot's of stuff going on there.... although it doesn't look like that is the main problem, i will need to investigate further there...
>
> Am 17.05.2010 um 17:00 schrieb Ingo Maier:
>
>> -XX:+PrintCompilation
>

And don't you have this dummy data already in the form of unit tests and the like?
  --Rex

On Mon, May 17, 2010 at 12:00 PM, Ingo Maier <ingo.maier@epfl.ch> wrote:

If you are sure your problem is class loading times, and not the JIT for example (you could check that with -XX:+PrintCompilation), couldn't you just run your hot paths with dummy data once?

Cheers,
Ingo