Game offers 3 metrics:

1. Cycles count. The most hardcore metric, sometimes requires a lot of creativity and imaginations to optimise this. Meaning: amount of ticks of time from the beginning unlti all the task conditions are fulfilled. Each cycle all your EXAs usually execute 1 line of code, however some operations can be blocked for a while and consume more time. Also writing to M register takes 2 ticks and MARK pesudo-instruction doesn't consume a cycle. If you have 10 EXAs working in parralel, they can do 10 instructions per one cycle. When every condition is fulfilled (usually it ends by death of the last EXA) game counts spent cycles. Also game runs 100 tests and puts the bigges cycles count to the metrics.
   Conditions can be:
   
   • create a file with the specific content
     
   • delete the specific file
     
   • modify or move files
     
   • leave no trace, which means all EXAs are killed
     
   • transmit signal sequence to hardware register
2. Size. Amount of lines of code including MARK. @REP N macro command is not counted itself but N generated code blocks will be counted to the metrics.
   
3. Activity. The easiest metrics for optimisation. Just counts amount of LINK calls.

Relativity easy to reach the top percentile here. REPL is your friend.
Imagine 3 consequent nodes: 801, 802, 803, one EXA works in 802, another in 803.
Trivial approach:

• EXA A
  
  LINK 800 LINK 801 NOTE DO SOME WORK
• EXA B
  
  LINK 800 LINK 801 LINK 802 NOTE DO SOME WORK

We have 5 LINK calls which means activity = 5

Just replace it into:
Now second EXA is created in node 801 instead of your host and it doesn't need to do extra 2 movements. Now activity = 3.

Size is more interesting metric in terms of optimisation. Sometimes it correlates with cycles count as well but not always.

By the way, blank lines are not counted, use it for readability!

Let's discuss some techiques.


Let's assume that your code requires to modify initial value

can be refactored into

This also decreases cycles count

When there are no more lines of code, EXA drops file and halts automatically.
Example:
from zine equals to

Use DROP only when you need to move EXA somewhere else without this file or when you need to grab second file

Use HALT only when you have condition branches or REPLicated exas and second branch can be executed without exception (exceptions handling described in next paragraph).
Example: get variable from radio and put positive modulus to file:
Here without HALT both branches are going to be executed


When there is an runtime error:

• no such link/file/hardware
  
• grab second file without dropping the first
  
• reading from end of file
  
• division by zero

EXA is killed.
Let's use it.

Reading from file:
Trying to read file at EOF causes exception and EXA halts:
New code snipppet does the same. Also it is greatly decreases cycle count.

Grabbing file without dropping it:
If first EXA doesn't drop file 200, it will do the job then reach mark A and crash due to access exception

No file/link/hardware
or
In those snippets it is unlikely that node 801 has link to 802 or file 200 so EXA is going to crash after reaching mark A.
However swapping nodes might require HALT:
After reaching mark A, EXA might be able to go to 801 and mess things up. So put some attention which part of code to use in condition branch or REPL.

When value exceeds 9999 or -9999 it is clamped. We can use it
can be effectively replaced to
which greatly decreases size and cycles count.

E.g. node structure is like 1=>1=>1=>1
So 2 EXAs
can be replaced to:
saving 1 line of code with proper exception trick


Let's assume we need to break when get 0
Equals to this snippet
Reason: when T is 0, FJMP works. When T is something else (include negative values like -1) TJMP works. TEST instruction overrides T to 0 or 1.

Note: HALT is removed because if mark is on the last line, HALT will be automatic. Also for non 0 value code will reach END mark but do nothing, so HALT can be omitted.

This also reduces cycles count, especially in loops.

The most interesting part. Main goal here is decreasing operations in loops which saves a lot of ticks.
However there are also some tricks to save couple of cycles here and there. First of all read previous chapter carefully because LoC Size optimisations often help to decrease cycle count as well.

Let's discuss cycles optimisation now.

It works only when you know exactly how many cycles are required.

Send5 entries from file

Write 0,1,2..10

Travel 800=>801=>802=>803=>804

Write 10, 8, 6 , 4, 2, 0

However when you start your program, @REP N will be replaced to N x block size lines of code.
Also you can't use nested @REP.
Each program has LoC Limit. If @REP adds too much code, your solution can't be compared with leaderboard.
This solution beats top percentile in terms of cycles count:
But it can't be counted because after launching there are 110 LoCs, but allowed size is 50 LoC.
However you have to replace smaller cycles which have known limits to @REP for improving cycle count metrics.


Write to file N,N-1..1,0 (N from another EXA):
To be honest, it is not the most optimal solution, can be optimised for 1 more cycle :D
So this loop consumes 3 cycles per item. Loop with TEST would consume 4 cycles.


Write to file 0, 1 .. N (N from another EXA):
Still 3 cycles per item.

Assume you have some independent tasks for your EXA which are using same X or T initial data
can be paralleled into
2 EXAs will do tasks much faster.


Now it is a time for heavy optimisations.
Let's return to our loops but change task from writing to file to transmitting data through M:
Copying to M takes 2 cycles. That's why loop item is processed for 4 cycles in total. Adding more instructions increases cycle count heavily, making programs really slow.
Solution is to split cycle from actual work thus executing jobs in parallel mode.
Here we are using REPLicated EXA as procedure (subroutine). Loop entry consumes 3 cycles and only handles looping, all calculations are performed in parallel by another EXA.
This method is easy to control and handle. But you migh need to eventually move clones to another node in case when work takes 3+N (N is free cell count in the room) cycles or more because producer (loop) becomes faster than consumer (current node) and current node can be filled with EXAs causing loop to wait when they are move away or halt themselves.

Okay 3 cycles for loop is good but I need to process data FASTER! I did previous trick but histagrams show much better results. Can you help me??
Yes, there are 2 ways of making 2 cycle loops: stateful and stateless.
Stateful:
Stateless:
First one is more useful but harder to handle. Second one is mostly useless but a bit easier to kill.
Both methods require another EXA with killer role. Killer must count how many cycles should this producer live and than kill it. Typical killer code:
It waits until unmanaged loop does all its job and then kills replicating EXA and it's last child.
Also EXAs have to move away from respawn point more actively in case when work takes 2+N (N is free cell count in the room) cycles or more otherwise process will slow down due to EXAs overflow.

I wanna be a SPEED DEMON like top percentile guys in chart! Is it possible to run things in real time?
Actually, yes:
EXA firstly creates new stateless copy and then thinks what to do next.
Using this approach you might need more than one killer. Also your EXAs should constantly move forward: Each operation within the node (including LINK to that node) occupies one free cell so if room has 4 free cells you shouldn't do more than 3 ops within it.
Example:
You might notice that this is not top percentile. So here you are! However difference is barely visible but this extra one cycle costs one extra EXA.


Previous approach can't work in some cases e.g. when you need to write to file. However it is possible to reduce loop execution time and make it close to 1 cycle per entry.
Solution is to split big (e.g 100+ loop) into tens and ones. Then process tens using @REP and ones using normal loop.

Note: handlers of tens and ones can be swapped

The problem here is that effectivenes of this approach depends on test data so you may need to change 10 in all 3 places to another value and empirically find out the best constant for this particular tests set.