Description: The Scriptforge.L10N method ExtensionFolder() takes a long time (more then 3 seconds) to run on Windows when it is executed the firs time in one macro, but not the second one. the lag occurs on Windows but not on Linux Steps to Reproduce: Open the attached file and click on button to execute a macro showing the error. NOTE that in the macros is used de APSO extension data to test. It should be changed to the data of an installed extension Actual Results: There is a lag in the first execution of the ExtensionFolder() method on Windows Expected Results: The execution should be almost instantaneous Reproducible: Always User Profile Reset: No Additional Info: Lag present in: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded ------------------------------------------- No lag on: Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Created attachment 192325 [details] File with a macro to test the error
(In reply to jcsanz from comment #0) > The Scriptforge.L10N method ExtensionFolder() takes a long time (more then Sorry, the method is not from Scriptforge.L10N but from Scriptforge.FileSystem
Usually scripts that involve ScriptForge take 1 or 2 seconds to start running the first time, due to the need to load the library. On my experience, this is faster to load on Linux than on Windows. I tested your macro on Kubuntu (it took less than 1 second to run the first time; the second time it was instantaneous). On Windows (running on a VM) it took between 1 and 2 seconds in the first run; the second time was instantaneous. Do you have this issue only with the ExtensionFolder? Did you try with other methods? @JPL, any thoughts here?
Another specificity of the first execution is that the list of extensions is preloaded. The loading of the list is done with GetDefaultContext.getByName("/singletons/com.sun.star.deployment.PackageInformationProvider").ExtensionList returning an array of arrays. Maybe a test on Windows of the duration of above line of code could contribute to find the root cause of the observed behaviour ? On my side I cannot reproduce the issue either.
(In reply to Rafael Lima from comment #3) > Usually scripts that involve ScriptForge take 1 or 2 seconds to start > running the first time, due to the need to load the library. As you see the load of library is done before the time messure > On my > experience, this is faster to load on Linux than on Windows. In this case it is true > I tested your macro on Kubuntu (it took less than 1 second to run the first > time; the second time it was instantaneous). On Windows (running on a VM) it > took between 1 and 2 seconds in the first run; the second time was > instantaneous. Yes as I said, my test in Linux was correct > > Do you have this issue only with the ExtensionFolder? Did you try with other > methods? Yes, I had the prblem only with this method, and yes I've tested other methods mostly in the Scriptforge.L10N service
(In reply to Jean-Pierre Ledure from comment #4) > GetDefaultContext.getByName("/singletons/com.sun.star.deployment. This statement takes a little more time in execute than others, but takes aceptable times. --- Further tests in a different Windows machines result in normal execution times, so probably the problem was (is) my Windows machine. So I think this bub can be closed with NOTOURBUG
Thanks to all for efforts done.
(In reply to Jean-Pierre Ledure from comment #7) > Thanks to all for efforts done. Thanks to you all for Scriptforge and for your kind help