GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2012-10-29T18:31:55.000+0000 |
Affected Version/s | Release 3.0.0 |
Fix Version/s | Release 3.0.0, Release 3.1.0, 2012 Sprint 22 JS, 2012 Sprint 22 |
Components | Tooling |
Labels | cli, js, qe-ios100112, regression, stud-performance-100112 |
Reporter | Dustin Hyde |
Assignee | Chris Barber |
Created | 2012-10-11T20:56:11.000+0000 |
Updated | 2012-12-11T00:36:18.000+0000 |
Preferences > Titanium Studio > Titanium > Default Android SDK takes 3 seconds to load.
This is a regression.
Steps to Reproduce:
1. Run Preferences > Titanium Studio > Titanium > Default Android SDK takes 3 seconds to load.
Actual Result:
3 seconds to load, initially looks broken.
Expected Result:
Instant load.
Note: As per Shalom, here is the command-line arg to get this preferences info:
titanium info -o json
Is this a Studio bug, or a CLI bug?
It appears to occur when the command is run from the command line, probably a CLI issue.
Moving bug to SDK.
High priority as the amount of time it takes makes Studio look unresponsive.
I just added support for limiting the results of the "titanium info" command. You can now specify specific "types" of data to fetch. Android info still takes some time since we call "android list" which is sloooooow. If you're just looking for the Android SDK/NDK path, you can try just running "titanium config android.sdkPath" and "titanium config android.ndkPath", but those are whatever is saved in the config and may not actually be correct or exist. You need to call "titanium info" to do some simple path and environment variable checks for the Android SDK path. Once you have the path, you should call "titanium config android.sdkPath /path/to/sdk" to save the value. If this comment works for the Studio team, please resolve this ticket.
I modified Studio to use the new call to grab just android or ios info when needed, but still wasn't satisfied with the results. Reverting to calling legacy was slightly better, but I think the general issue here is that we're not re-using info we've already grabbed. Our SDKLocator code is _horrible_ and the pref page doesn't ask the existing instance for the values on open, it asks for it all again (even though we always have an instance with the details of the preference values). I'm working on cleaning up that code since it's pretty bad. That way we can re-use the stored info for locations we've already looked up (in some LRU cache of size ~3).
I think you can resolve/close this ticket, because I was able to show a speed improvement using the new -t flag to grab specific pieces of data. Grabbing all info took ~1.6s on the command line for me. Grabbing android takes ~1.2s and iOS ~0.2s. So I think the CLI work here is OK. I have opened a ticket for Studio, TISTUD-2559, that addresses our need to use these new switches and try to improve performance on our end.
Just out of curiosity, what Android info are you using? Do you need the AVDs? Do you need the addons?
This was resolved with TIMOB-11500.
Closing as fixed. Tested and verified with: Titanium Studio, build: 3.0.0.201211301903 Titanium SDK, build 3.0.0.v20121204181658 Titanium SDK, build 3.1.0.v20121204181803