SDK on Windows: build/run taking a lot longer than it used to [released]
It's been a while since I played with the SDK, but it used to take around 10-20s from clicking run to having the program running in the emulator (that was during SFOS 2.0ish), now even rather simple program takes about 2 minutes to show up. Is it the intel bugs that were supposed to impact virtualization, or some misconfig on my part? (didn't really change anything and just installed the default build targets, so doubt it)
EDIT: btw this is on win10, maybe there was no regression on linux, no idea
EDIT: I think this was fixed in 3.1 (yup, checked the release notes, under fixed: SDK on Windows: build/run taking a lot longer than it used to, closing), or at least right now deploying as RPM to the emulator is taking 15-20 seconds and the hangups are gone, haven't tested yet the 3.2 that was just released, I guess this can be closed unless people still are experiencing this issue
check your emulator config, give more ram and more cores.
coderus ( 2019-11-07 20:40:36 +0200 )editnot emulator, build engine vm. but you can improve emulator as well.
coderus ( 2019-11-07 20:41:06 +0200 )edit@coderus thanks, I gave both 2 cores and 2GB each, but I don't think it's that, it's just idling for long whiles, at start for example it hangs on 'acquiring lock' for half a minute with practically 0 cpu utilization, seems like rpm validation is now performed by default, so that could explain the last 30s probably (also not sure if last time translations were included by default, now got ts file for german(?) by default, maybe this also adds a bit, not sure), but even with just deploying binaries from start to finish a simple qml only program with 4 pages took 2:36
szopin ( 2019-11-07 21:07:09 +0200 )edit@szopin I was able to reproduce it on one Windows machine - there are really some unwanted delays. Under investigation.
martyone ( 2019-11-07 22:38:47 +0200 )editit does not seems to be slower for me, but I have different issue, for some reason I cannot update repos for i486 target. I had to do it manually by ssh. zypper say "no write rights to cache", I have overcome it by --solv-cache-dir
Bobsikus ( 2019-11-10 18:02:36 +0200 )edit