What makes loading a javacpp library relatively slow on Android? #287
Comments
|
Set the "org.bytedeco.javacpp.logger.debug" system property to "true", and check the log to make sure it's not trying to load libraries you don't need. |
|
I added |
|
I suppose we could add options to let users have more control over what gets called in |
|
As @rajib3hasan found out in issue bytedeco/javacv#1168, it looks like loading classes on Android is pretty expensive, even when they are already loaded. This is something else we should look at. |
|
It takes time to load library classes while creating Instance for the first time. Then it takes usual time. Here is the log i have found ... time: 8376 |
|
@rajib3hasan Can you do the same with JavaCPP 1.4.2? |
saudet
changed the title
|
As Damon Horrell found out in the following thread, this doesn't affect only Android: |
|
Actually, it looks like calls to /cc @caaiofarias |
|
Loading should now be fast with JavaCPP 1.5.3 on all platforms, but please let me know if anyone is still having issues with this. Thanks for the feedback! |
|
We have at least 40,000+ classes on our classpath when launching some of our larger apps. Bytedeco Code When I load this up in YourKit, to see what's going on, it takes longer, presumably because YourKit injects a lot onto the classpath.
We are running I did a search for how many classes are on the classpath for our application: Code: |
|
Looks like something wrong with your JVM? Class.forName() is taking almost 100% of the time. What's going on in there? |
|
@calvertdw Most of the calls to Class.forName() probably happen in Loader.putMemberOffset(), to fill the map for Loader.offsetof() and sizeof(). You may be able to skip that, depending on what your application needs. Can you try to comment out the Class.forName() in Loader.putMemberOffset() and see what happens? If it works for your case, we can add a system property to let users disable that at runtime, or add a cache or something. |
|
Hi Samuel, thanks for the help. I got swamped with other stuff, we'll give this a shot. By the way I was using OpenJDK above. I didn't get to test with other JDKs yet. Are large classpaths working okay for some other JVM? |
|
I don't know, the only issue that I know about had to do with Loader.findLibrary() as above, not Class.forName() directly. |
|
@calvertdw Actually, thinking about it some more, I'm guessing one of the libraries that you're using is making Class.forName() slow, just like Loader.findLibrary() used to make Class.forName() slow. Either way, if you can afford to skip Loader.putMemberOffset(), that's a fine workaround. |
After converting to javacpp, the
System.loadLibrary()call takes 30 to 200 ms. It's an Android project with a simple single-function native library at this point. Without javacpp, the native library loads in just a few ms. What is happening during the load that takes so long, is there a way to make it faster?The text was updated successfully, but these errors were encountered: