(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?
(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 eval
ing 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.
Whatâs up with the â[sic]â? I donât see any spelling or grammar mistakes.
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).