[Loader] improve performance of resource extraction and library search

[HannesWell]

With this PR I suggest changes to reduce the runtime of resource extraction and library search performed by the javacpp.Loader.

My benchmark is a stripped variant of the embeddedpython.Python that uses only javacpp and cpython (but not numpy) and the 'regular' variant of embeddedpython.Python but with updated javacpp dependencies. The benchmark is just the following program, which is absolutly dominated by the initialization of the embeddedpython.Python :

long start = System.currentTimeMillis();
Python.put("a", 5);
Python.put("b", 3);
Python.exec("v = a/b");
Object x = Python.get("v");
System.out.println(x);
System.out.println("Took " + (System.currentTimeMillis() - start) + "ms");

On my Windows 10 computer this program takes (when all files are already cached in a previous run) with the current javacpp master 2000ms+-20 for the stripped version respectively 3630ms+-20 for the regular version.

With the suggested changes, the stripped version takes around 800+-20ms and the regular version 1400ms+-20. So this improves the runtime of the initialization by more than the factor of two.

[HannesWell]

Maybe this also useful regarding issues #452. The most significant improvements from this PR were achieved by avoiding calls to File methods.

[saudet]

Maybe this also useful regarding issues #452. The most significant improvements from this PR were achieved by avoiding calls to File methods.

If you know of a more efficient way without changing the logic, please try to do that! Thanks

[saudet]

So, is there anything in particular that is preventing you from making progress with those pull requests?

[HannesWell]

So, is there anything in particular that is preventing you from making progress with those pull requests?

It is just my limited time and shifted priorities, but I definitely plan to complete this PR (as well as my other open PRs!) I hope/expect to have some free-time around the christmas/new-year days to complete this and the others.

[saudet]

BTW, concerning symbolic links on Windows, we could definitively disable them and assume by default that they are never supported. The user could still enable them with some system property, but since they are not available to users by default, and with bugs such as https://bugs.openjdk.java.net/browse/JDK-8003887 that seem like they are never going to get fixed but that @devjeonghwan found can still cause problems, it doesn't sound like we should be relying on them for anything on Windows. But we should still be able to enable their use in JavaCPP for users that really need them.

[saudet]

Based on suggestions in this pull request, I've updated a couple of things in commit https://github.com/bytedeco/javacpp/commit/e8b5734f7d0469478f399bb58e0fd3cfe4af1906. With these modifications, it takes a bit less than 1200 ms on my Windows 10 machine to execute the following, when everything is already cached, extracted, and all:

        Py_Initialize(org.bytedeco.scipy.presets.scipy.cachePackages());
        org.bytedeco.numpy.global.numpy._import_array();

I haven't tried to do something about the unnecessary calls to loadLibrary(), but it wouldn't even gain us 100 ms, so I'm reluctant to change the logic there just for that. If you see other places where we can gain more, please update this pull request! Thanks

@yukoba Does your javacpp-embedded-python incur any additional overhead that we should know about?

[HannesWell]

Thanks for implementing the changes and sorry for the delay. Seem that my estimation was bad but I hope to be able to check for possible updates of this and my other PR/issues in the next few weeks.