"We find that global names [sic] are frequently constants, and declaring them as such greatly improves performance"

(From https://docs.julialang.org/en/stable/manual/performance-tips/#man-performance-tips-1 )

Really?? Does the compiler not itself determine that a global variable value is constant, and optimise accordingly?

How would one do that?

Well, if a variable is assigned only once in the program than its a constant. So the compiler should be able to realize that, but it might be expensive to check that.

There’s this function called eval though. It wouldn’t help in the REPL either (which calls eval repeatedly). It’s also generally impossible to know how many times a function is called, so it would only help if the assignment is at top-level only and never in a function. The bottom line is that one could only do this by disallowing evaling into a module, which would prevent great packages like Revise from working. This kind of analysis may seem plausible coming from relatively constrained statically typed languages where the compiler sees all code that can possibly be called before anything is run, but that’s not the way Julia and dynamic languages in general work.

8 Likes

What’s up with the ‘[sic]’? I don’t see any spelling or grammar mistakes.

2 Likes

Perhaps the implication is that “global names” is not the correct term here? @chrisjj, what did you mean?

Would it be possible to treat global variables as anonymous functions returning a constant , and to invalidate all functions depending on it whenever their return type changed?

I think it would achieve the desired result, but may have other implications for example with a global variable that keeps changing types

Perhaps the implication is that “global names” is not the correct term here

That’s true.

So you need to wait for the world age to update just to access a changed global?
Sounds pretty annoying (note that the discussion here is for non-const globals).