`bzero(256)` compiles to ` byte 0x00000000000000000...` in TEAL, using up a lot of space.

[nullun]

TEALScript

import { Contract } from '@algorandfoundation/tealscript';

class Demo extends Contract {
	@allow.create('NoOp')
	demo(): void {
		const data = bzero(32);
	}
}

TEAL

demo:
	proto 1 0

	// demo.algo.ts:6
	// data = bzero(32)
	byte 0x0000000000000000000000000000000000000000000000000000000000000000
	frame_bury -1 // data: bytes
	retsub

I'd have expected.

demo:
	proto 1 0

	// demo.algo.ts:6
	// data = bzero(32)
	int 32
	bzero
	frame_bury -1 // data: bytes
	retsub

[joe-p]

Yeah I made this decision because I think generally people run into opcode budget before they hit program size limit, so if a literal is used as the argument it will just write out the byteslice. I could turn this into a command-line flag to let the user decide if it should optimize for size or opcode cost.

[nullun]

Ah OK. In this case it's just a single extra opcode cost on a somewhat infrequently used opcode, so I wouldn't expect it to be the optimisation that makes or breaks someone's ability to run within the budget constraints.

In general does TEALScript prioritise program size over opcode budget, or is it an opcode by opcode judgement? Since budget can be increased greatly, whereas program size is restricted to 3 extra pages max, it could be argued program size is more limited.

I do think a compilation flag would help here, or even an optional one in the code itself. But I'd recommend having fine control over what types of optimisations happen and where if possible, otherwise people may have to manually alter the TEAL after compiling which we would want to avoid.

[joe-p]

In general, my philosophy for TEALScript has always been to optimize for the thing that is the least obvious when it becomes unoptimized. In this case, if someone has a program that is too big that will be immediately obvious and it won't even compile because TEALScript does a call to algod to get the PC mapping. If someone were to have bzero in a loop they might not properly test it with enough iterations and only later find out that they run out of opcode budget once the contract scales to a certain point, where every single opcode cost is important.

But yeah agreed that opinionated stuff like this should be configurable.