I'd recommend just solving the puzzles, don't worry about optimizing... But since you're going to insist anyways

The reason the code you have is so slow, is because all the work is being done on the first 3 input nodes. A large portion of the TIS-100 is that you work in parallel. This means trying to even out the load as much as possible. My main solution usually involves block 7 (mov any, down) instead has move left, acc and add right, before moving down. The middle block then just becomes a little mechenism to tell the left and right sides if they should return the number or return 0.

Another big thing of optimizing is i notice you have:

[code]
JEZ 0
JGZ 1
JLZ -1
[/code]

which encompasses numeric labels. I'd recommend shortening them to the last 2 letters of the result or a more concise label name. 1-2 letters is more than enough to make it more obvious. Plus JRO doesn't follow labels, so doing the above would result in code that doesn't work and you don't know why.

Alright so back to the three compares. Don't compare for all 3 results, instead check for the 1 result you're interested in. So... Block 2 you'd be interested in JLZ, once you do that jump to the working part of your code. All other results (EZ, GZ) are immediately after JLZ code. So if i re-write it:

[code]
START:
MOV UP, ACC
SAV
MOV RIGHT, ACC
JLZ W
JMP START
W: SWP
MOV ACC, DOWN
[/code]

Another thing is you aren't working with the result, so it would probably be better if you work with it once you have an answer, which removes SAV/SWP

[code]
START:
MOV RIGHT, ACC
JLZ W
JEZ Z
MOV UP, NIL
JMP START
W: MOV UP, DOWN
JMP START
Z: MOV UP, RIGHT
[/code]

If you don't mind going down the road of insanity and working with JRO, you can do the following:
[code]
ST: JRO RIGHT
NOP
MOV UP, RIGHT
JMP ST
NOP
NOP
MOV UP, NIL
[/code]

while block 3 has:

[code]
ST: MOV UP, ACC
ADD 2
ADD ACC
MOV ACC, LEFT
MOV ACC, RIGHT
SUB 4
JEZ Z
JMP ST
Z: ADD LEFT
ADD RIGHT
MOV ACC, DOWN
[/code]

Let's explain this. JRO jumps X number of instructions as specified by an input. 0 is your problem input because it just repeats JRO immediately with no context of what to do. SO:
ADD +2:
-1 -> 1
0 -> 2
1 -> 3

ADD ACC:
1 -> 2
2 -> 4
3 -> 6

Lastly i check for 0 at the end by subtracting 4, if it is zero I'm getting the value back so i just add what's left and shove it down.

So finally, multi-tasking. Even if your code is bad, or even optimized you can in some cases get more work done simply by copy/pasting the code and working with it afterwards. This assumes you have room for a few instructions, and your path that you work isn't odd, in this example the pathing is a little odd, but a previous one for just doubling the numbers you'd do:

[code]
MOV UP, ACC
ADD ACC
MOV ACC, DOWN
[/code]

Well, if you forward a value first you can then be working on it in another block, and then forward the after result afterwards. Takes up more space but you're working twice as hard. Not always efficient though.

[code]
@2:
MOV UP, DOWN #forward 1st value
MOV UP, ACC
ADD ACC
MOV ACC, DOWN

@6:
MOV UP, ACC
ADD ACC
MOV ACC, DOWN
MOV UP, DOWN #forward tail second value's result
[/code]

Limiting how many cycles your code works in and trying to do a little of the load, even if it's insignificant and then moving it to the next step could make the entire thing faster.

With that in mind, a lot of low level tricks take a while to build up and just learn from mistakes, and just seeing the answer doesn't mean it sinks in unless you came up with that result that does as well, or in a few rare cases even better than the best known result. (i have at least 2).

edit: Glancing at the other code after i wrote this i see you did some of the improvements already to some degree... So sorry on that.

edit2: Wow, just wow. Just re-wrote the solution and got it much faster than i expected... Here's the code