Reconsider polling approach for performance reasons

[mrcljx]

Currently each first (i.e. non-reentrant) request from Native to JS causes this behavior:

• Client calls transit.eval(...)
• Transit.java pushes EVAL-Job to the actions stack
• Transit.java triggers transit.poll() in Transit.js via loadUrl
• Transit.js does a prompt(POLL)
• Transit.java pops EVAL-Job from the actions stack and...
• Transit.js receives EVAL-Job
• Transit.js processes EVAL-Job
• Transit.js returns result of EVAL-Job
• Transit.java creates a NULL-Job and...
• Transit.js receives a null-Job (end of poll)
• Client receives result of EVAL

Thus the following piece of code takes ~7200ms (on Samsung Galaxy Android 4.2.2) to run where 1000 sequential calls from JS to Native only take ~4000ms.

for (int i = 0; i < 1000; i++) {
  transit.eval("someJSFunction()");
}

This could be optimized by moving the EVAL-Payload to the loadUrl directly.

[HBehrens]

Do you have the chance to measure the impact of loadUrl and prompt separately? If I understand the flow correctly the example above does one loadUrl and two prompts (first to receive package, second to deliver results and ensure "end of poll"). Putting the initial job into the request would eleminate the first prompt then. Is this worth the redesign and risk that the URL's length exceeds any 4k (or similar) limits?

[HBehrens]

How does this ticket relate to the recent improvements mentioned in #2 ?

[mrcljx]

This issue remains in the "to discuss" category - didn't change the poll-design for now (also the Trigger.io benchmark doesn't cover the 1000 calls inited by Java case).