Hex literals are faster than Decimal literals

[Ricardo Fernández Serrata]

I'm not talking about text strings, I really mean integer numbers, more specifically number literals. I was looking at the timings of 2 identical flows, the only difference is that one of them has all instances of the value 256, replaced by 0x100, and this "hex flow" was slightly faster than the decimal one, even in a loop. The hex lasted 1.90s on average, while the decimal lasted 1.96s. The hex had a maximum latency of 1.95s, dec had a max of 2.04s. Minimums were 1.87 and 1.90 respectively.

Flow files store numbers as raw binary, not text, so there shouldn't be any difference between hex and dec. It makes sense that parsing decimal text is slower than hexadecimal, but the nonsense is that the interpreter is STILL slow even after the flow has been loaded to memory. The benchmark I was doing was timing everything from the start of the flow (just after the input data has been stored to variables, so initialization won't affect timings) and there was a loop with MANY iterations, so this slowness is not because of "compilation latency". Why does this happen?

[Henrik "The Developer" Lindqvist]

Number values are stored as 64-bit IEEE 754 floating point, the hexadecimal and regular "scientific" literal are just for display purposes, e.g. when view it in the editor, logging, etc..

There's no "compilation latency" since flows are never compiled, they're interpreted directly from the AST, which is the format they're stored as.

Trying to "benchmark" flows is futile since there's so much Automate does "behind the scene", e.g. regularly storing the fiber to disk (database) as it's being executed, co-operative multitasking, etc.. Android may also adjust thread/process priorities at any time.

[Ricardo Fernández Serrata]

I already knew the information in the 1st paragraph. The 2nd paragraph is something I didn't know. Thanks for the clarification and your time

[Ricardo “Rudxain” Fernández Serrata]

I made a minimal reproducible example (see attachment), to avoid all the syscalls that the original RC4 did.

I benchmarked each flow by running them in the following orders: 0101..., 000111, 111000. (where "1" is hex and "0" is dec). This way, we can reduce the influence of external-factors, such as caching and thermal-throttling.

I suspect the difference happens because of how JVM/ART JITs Automate's bytecode when running the flows

[Shari Shark]

No disrespect, but using hex is just not readable unless one is very good at converting it mentally. 

As you said, this was tested across MANY iterations. And the difference is only 0.09s at the worst. A network call is mostly more than this difference. 

In reality, there won't be any noticeable difference in real world usage. Imo, sacrificing legibility for that bit of efficiency is just not worth it. 

--
You received this message because you are subscribed to the Google Groups "Automate for Android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to automate-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/7535ab8f-595c-4f6f-a77d-d6caca699910n%40googlegroups.com.

[Henrik "The Developer" Lindqvist]

As said, there's no JIT since Automate use interpreted code.

[Ricardo “Rudxain” Fernández Serrata]

@Shari I agree, but would you rather read `65536` or `0x10000`? Hex is much cleaner when dealing with simple binary patterns, such as 0x5a5a5a5a, or 0x7fff.

@Henrik I know, I meant the APK bytecode, not *.flo. Every non-native APK contains *.dex bc files, which are AOT & JIT compiled by ART (previously, only JITed by Dalvik). So perhaps the VM is recognizing some patterns in the execution of the AM interpreter?