give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: The performance of native bridge invocations shall be improved in Q1  for both iOS and Android. This will be done by creating an optimizing  javascript-to-javascript compiler that identifies non-performant  Titanium API use-cases and transforms them into performant native  bridge invocations.    The plan for completing this task is:    1. Automate collection of app performance data.    2. Identify Titanium performance bottlenecks from performance data.    3. Analyze javascript AST for common Titanium API idioms.    4. Create optimization algorithms (AST transformations) for these     idioms identified as performance bottlenecks.      From <USER>s README.md in his compiler prototype project:    Compiler Prototype  ==================    The compiler prototype is a simple set of compile-time optimizations  that are applied to speed up native bridge invocations.    Concept  -------    The concept is very simple.      The Javascript native bridge binds a set of JavaScript objects (the  Titanium API) and eventually a method is bound into a callback  implementation in native land.  The JS engine performs native bridge  calls to lookup the JavaScript object and eventually invoke the bound  native function in this simple example:     > Ti.API.log('foo')    The JS engine makes the following invocations underneath the cover:     > Ti => Object   > Object.API => Object   > Object.log => Function   > Function('foo')    So, a simple one-liner requires 4 invocations in the JS engine.    Additionally, in this example, foo is an argument that must be  marshalled from a JS native object into a native object.  In  Objective-C, this turns a JSValueRef (or JSStringRef) into a  NSString. This happens before the underlying JSFunction is mapped into  an Objective-C method.  To make matters worse, in Objective-C, we have  to do additional lookups to find the appropriate TiModule and then  build an NSInvocation to invoke the method against the Objective-C  class.  All of this takes time.    This prototype attempts to speed up the invocation above by performing  a few simple steps.    First, we avoid the Object lookups by turns a Titanium API into a  bound symbol in the JS engine. So, Ti.API.log become T$1 (as an  example).    Second, we attempt to speed up static arguments that are required to  be marshalled during invocation into a symbol table which are only  marshalled once. The symbol table is pre-compiled and subsequent  references of the same symbol will use a pre-marshalled copy.    Third, we pre-bind a compiled method and set of pre-marshalled  arguments into a jump table. This is similar to using a function  pointer (but as an instance of a compiled pointer to a module and  invocation).    The result is that you can get 50-75% pure invocation speed ups.  For  methods that have static arguments, you can achieve even better  results.    Limitations  -----------    The current prototype uses a titanium module and requires a compile  method to be called at the top of each compiled file to load up the  symbols and bind the symbols. This has convenience in that we can do  it without having to make any changes to Titanium itself.  However, we  may want to consider adding the compile method into Titanium  (unpublished) to make maintenance easier and eliminate the need for a  module.    The second limitation is that we are speeding up only function calls  and a few global symbols (such as Ti.UI.FILL).  Eventually, we may  want to do the same to properties.    Third, the prototype is using a compiler hook (good) but only is  working with Alloy.  This is not a limitation per se, but i didn't  want to have to deal with figuring out how to redirect the compiled JS  files into a separate temporary directory and causing XCode to point  at that instead of Resources -- since we don't want to override  Resources (except in Alloy, that's how it operates, so that's OK).    Fourth, I'm using a uglify-based compiler by hand instead of using  Bryan's titanium code processor.  The current implementation of the  code processor doesn't allow you to mutate code in his plugins (or in  the processor itself).  Ideally, this would actually be a code  processor plugin that would simply mutate code in a pipeline during  compilation.    Fifth, the current prototype is iOS only.  This is because I'm most  familiar with iOS and don't know the Android compiler / bridge for V8  as well as the old version.  However, I think this same concept works  for Android conceptually.    Six, since I'm not using the code processor, I'm not using the JSCA  file to understand the API. Moving to the code processor eliminates  that issue.    The last overall limitation is that we might want to actually  pre-compile out the jump tables and use actually compiled function  callbacks instead of the TiCompiledMethod object.  If we moved to more  of a true compiled / generated code, that would be rather trivial.  This would likely give us even more speedup and much less object  garbage and much lower memory.  You would simply generate the C  function that would directly call the module and method instead of  having to have a generic TiCompiledMethod and you could by pass the  entire Kroll overhead. I believe the new V8 compiled bindings do  something similar in Android.    Components  ----------      ## CLI Hook    The CLI hook file is under plugins/ti.compiler/hooks and in the file  ti.compiler.js      ## Module Source    The module source for iOS is under compiler_module.      Notes  -----    The ti.compiler plugin must come after the ti.alloy in tiapp.xml.      Afterthought  ------------    I think this concept can be dramatically further expanded to really  build a compiler that can pre-<USER>code and optimize, compile and  generally make performance a lot faster than it does today.    ## Collapsing properties    For example, take the following code:     var v = Ti.UI.createView();   v.width = Ti.UI.FILL;   v.height = Ti.UI.FILL;   v.backgroundColor = "red";   w.add(v);    This could easily be re-written to be much faster (prior to  optimizations from prototype):     w.add(Ti.UI.createView({width:Ti.UI.FILL,height:Ti.UI.FILL,backgroundColor:"red"}));    After optimizations further:     w.add(T$1());     ## Multiple invocations    Another example that is common, adding multiple objects to a view  heirarchy.     w.add(view1);   w.add(view2);   w.add(view3);    This could be optimized into:     w.add(view1,view2,view3);    In this example, passing 3 objects over a view to add to the window  will be MUCH faster because you go from 3 separate invocations to one  and more importantly, because this method is required to be invocked  on the UI Thread, 3 separate UI thread blocks.    Additionally, at some point, you could move the same optimized method  onto the native side such as it would turn into the following:     T$1();    And on the native side, it would simply do the work of adding the 3  views to a window by native references.    ## Subsequent code blocks    My ultimate belief is that most of the static code written in Titanium  JS can be pre-compiled and essentially reduced into few JS engine  functions.    Take the following static code block:     var w = Ti.UI.createWindow();   var v = Ti.UI.createView({width:TI.UI.FILL,height:TI.UI.FILL,backgroundColor:"white"});   var b = Ti.UI.createButton({    text:"Hello",    width:TI.UI.SIZE,    height:Ti.UI.SIZE   });   v.add(b);   w.add(v);   b.addEventListener(function(){    alert("hello world");   });   w.open();    This should be able to be reduced in JS code to:     var r$1 = T$1(), w = r$1[0], v = r$1[1], b = r$1[2];   b.addEventListener(function(){    alert("hello world");   });   w.open();    We should be able to take subsequent code blocks that are static and  collapse them into code blocks in native that can be mapped to one JS  symbol pointer.    ## String consts    We might be able to get much better optimizations in the JS engine by  turning static code strings into JS consts at compile time.  In a ton  of cases in an app, you will use inline strings.  Its generally faster  to declare them as a const and then use the const variable name  instead.  This could be a simple optimizations done by the compiler.    ## Dead code removal    We need to remove dead code or unused variables and functions.  For  example, in Alloy in the alloy.js file, we define a function named  isTabletFallback.  This method isn't used.  We could simply optimize  on compile and deterine which functions / symbols are reachable and  then remove them if not.    For example, Alloy generates the following:     var Alloy = require("alloy"), _ = Alloy._, Backbone = Alloy.Backbone;     Alloy.createController("index");    This is useful is you need to reference Backbone or underscore  libraries in the app.js stub.  However, in almost all scenarios, the  developer never does this in a standard Alloy app.    The code above could be easily reduced to the following if it's not  modified:     require('alloy').createController('index')    This creates no variables in memory that have to be later garbage  collected and is much more efficient in execution.        - <USER> 
Answer: 2345687.0