ID:2229756
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
A lazy var's initialization occurs when the var is read for the first time.
Lazy variables are specified using the lazy var modifier, similar to global and tmp.

This saves us the trouble of using if(isnull(v)) v = ... in many cases, and may give a significant performance boost when used appropriately.
I'd *love* this.
+1
+1
This might be rather difficult to pull off.

Compile-time inits like mob/var/list/blah=new generate an init proc that's shared by all members of that type, and all such vars belonging to that exact same type have their instructions added to the init proc. So the init proc might look like this:

blah = new
blah2 = new
blah3 = list(1,2,3)
...

The lazy var concept would involve creating micro-procs for each such var, and calling them on var read if the lazy flag was detected. There's really no easy way to simply call the micro-proc instructions directly, which means proc call overhead comes into the mix.

Also, this lazy flag check on reading a default var would happen every time a var was read that had a default value. That simple if() would add a tiny overhead just on its own, and that overhead would apply to every single default var read.
This has no benefit for the players of BYOND. There's plenty of ideas that have more bang for the buck for the actual players but I'm mostly seeing people fawning over ideas like this.
In response to Tens of DU
Tens of DU wrote:
This has no benefit for the players of BYOND. There's plenty of ideas that have more bang for the buck for the actual players but I'm mostly seeing people fawning over ideas like this.

This isn't meant to be a change for "players"; it's obviously a quality of life request for developers.

As a side note, I don't see anyone fawning over this idea. The longest reply other than Lummox's and yours is 3 words.
Anything that can boost performance is potentially great for the player experience, especially in large games. The problem here is, I don't see an implementation path that would work as advertised without making things worse for lots of other var accesses.

Heck, I still look for ways to trim down proc call overhead. If I find a way to shave 5% off of the start and end time inherent to every call, I'll jump on that.