Titanium JIRA Archive
Alloy (ALOY)

[ALOY-620] Reduce compile time

GitHub Issuen/a
TypeStory
PriorityHigh
StatusOpen
ResolutionUnresolved
Affected Version/sAlloy 1.2.0, Alloy 1.1.0, Alloy 1.0.0
Fix Version/sn/a
ComponentsTooling, XML
Labelsnotable
ReporterDavid Bankier
AssigneeFeon Sua Xin Miao
Created2013-04-13T12:43:40.000+0000
Updated2015-06-08T17:39:30.000+0000

Description

Here are list of ways or issues that if solved can speed up compile time for quick iterations: 1. Currently all controllers are rebuilt irrespective of whether the view/style/controller has been modified since the last compile. 2. The alloy libraries are also copied to the Resources directory every time unnecessarily (e.g. alloy/underscore.js, alloy/sync/properties.js, etc). I think we should only compile and/or copy when necessary. 3. While I understand the value of uglify js, I'm not sure if it is necessary for quick test iterations. 4. It would be nice to have a compiler flag so that the platform constants, (e.g. OS_IOS) are not uglified out. (This would help support x-platform pushes for TiShadow during development)

Comments

  1. John C. Bland II 2013-04-13

    I couldn't find the vote button but +1. Time to test is one of my biggest hindrances with Ti. For #3, uglify should happen for release only then debug does without it.
  2. Tony Lukasavage 2013-04-13

    My thoughts so far: 1. definitely 2. definitely 3. uglify-js does a lot more than just minify and obfuscate, as most people use it. We do a number of compile time optimizations by manipulating the AST with it. In addition, some of the functionality of Alloy relies on changes that might relevant to uglify-js. It's not as simple as turning it off. 4. The platform constants you mentioned (OS_IOS for example) don't exist as variables. They are used purely by uglify-js as mentioned in #3. To leave them in is to invite undefined variable errors.
  3. David Bankier 2013-04-13

    (1) and (2) - great (3) - curious on what else it does and whether it is needed (and can be avoided) during development and testing. Will look at your source code. (4) I realise you pass the constants to uglify, but wouldn't injecting the constant values in the source (i.e. each file) achieve it?
  4. Fokke Zandbergen 2013-05-31

    +1 I know Tony is modularizing (is that a word) the Alloy compiler, so I guess that opens the way for either manual or by-deploytype disabling of even more features 'unneeded' during development or using with TiShadow in particular: 1) Disabling cleaning Resources (So that the next one is possible) 2) Disabling checking for and recopying 'BASE RUNTIME FILES' (Alloy + Lib files - don't change that often) 3) Disabling 'builtins' AST module and just copy all builtins 4) Disabling 'optimizer' and 'compress' AST modulse and just inject OS_IOS variables in all files 5) Disabling sourceMapper (of no use to TiShadow) The goal would be to have less optimized code in less time.
  5. Fokke Zandbergen 2013-05-31

    On my local Alloy I just added the option to disable sourceMapper. Benchmark went from 3.3 tot 2.9... Pull-request: https://github.com/appcelerator/alloy/pull/139
  6. Fokke Zandbergen 2013-05-31

    Another PR that allows you to not selectively but just copy all builtins: https://github.com/appcelerator/alloy/pull/141 PS: Don't really get why the AST modules are called twice, in both sourceMapper.js and the compiler's index.js?
  7. Fokke Zandbergen 2013-05-31

    And final PR for today for not cleaning up: https://github.com/appcelerator/alloy/pull/142
  8. Tony Lukasavage 2013-07-24

    Converting this to an ongoing story with subtasks detailing each possible improvement

JSON Source