# Why do global variables impact performance so badly?
**URL:** https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293
**Category:** Performance
**Created:** [September 8, 2020, 8:57pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293 "2020-09-08T20:57:50Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@originalsouth](https://discourse.julialang.org/u/originalsouth)
#### Post date: [September 8, 2020, 8:57pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/1 "2020-09-08T20:57:50Z")
I have two almost identical codes:
```julia
#!/usr/bin/env julia
using Random
if(length(ARGS)==1)
N=parse(Int64,ARGS[1])
else
N=1000
end
function play()
r=0
counter=0.0
while r<1.0
r+=rand(Float64)
counter+=1
end
return counter
end
function drive()
e=0.0
for i in 1:N
e+=play()
end
println(e/N)
end
@time drive()
```
with `15.485858 seconds (300.53 M allocations: 5.985 GiB, 0.59% gc time)`
and
```julia
#!/usr/bin/env julia
using Random
function play()
r=0.0
counter=0.0
while r<1.0
r+=rand(Float64)
counter+=1.0
end
return counter
end
function drive(N::Int64)
e=0.0
for i in 1:N
e+=play()
end
println(e/N)
end
@time drive(length(ARGS)==1 ? parse(Int64,ARGS[1]) : 1000)
```
with `4.922885 seconds (468.38 k allocations: 21.594 MiB)`
Why is the latter a factor three faster – or why does the former use so much memory?
Thanks!
---
### Author:  [@WschW](https://discourse.julialang.org/u/WschW)
#### Post date: [September 8, 2020, 9:17pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/2 "2020-09-08T21:17:43Z")
Since `N` is a non `const` global it is possible for a value with a different type to get assigned to it. As a result Julia has to generate more generic code that is valid for potentially all types.
---
### Author:  [@bashonubuntu](https://discourse.julialang.org/u/bashonubuntu)
#### Post date: [September 8, 2020, 9:22pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/3 "2020-09-08T21:22:39Z")
Please also read
> **[7 Julia Gotchas and How to Handle Them - Stochastic Lifestyle](https://www.stochasticlifestyle.com/7-julia-gotchas-handle/)**
>
> Let me start by saying Julia is a great language. I love the language, it is what I find to be the most powerful and intuitive language that I have ever used. It’s undoubtedly my favorite language. That said, there are some “gotchas”, tricky little...
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [September 8, 2020, 10:57pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/4 "2020-09-08T22:57:09Z")
The answer to this should be that globals are fast as long as they are type annotated. Unfortunately, type annotated globals aren’t supported yet. There’s no great reason why not other than no one has implemented it yet.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [September 9, 2020, 1:00am UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/5 "2020-09-09T01:00:42Z")
What do you mean by type-annotated globals?
You can define `const` globals, the type (and the value) of a `const` global is assumed to be unchanging. You only refer to a global after you define it. Consequently, `const` globals are _de facto_ type annotated.
Do you mean: “we could have non-`const` fast globals in the future, their only restriction is that they cannot change type (but they could change value)”? We kinda already have that, you just need to make a global `const N = Ref(parse(Int64,ARGS[1]))` (the value is accessed by `N[]` and can be changed by `N[] = new_value`). Its type and value are constant (but its value is, in fact, a memory address), and the value pointed by the memory address can be changed safely, basically giving you a non-`const` type-annotated global.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [September 9, 2020, 1:47am UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/6 "2020-09-09T01:47:50Z")
what I mean is that `i::int=0` doesn’t work in the global scope. If it did, you could have fast non-const globals since the compiler would know their type.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [September 9, 2020, 1:53am UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/7 "2020-09-09T01:53:52Z")
Ok. As I have pointed out above, the reason probably nobody implemented them yet, is just there already is a good workaround.
---
### Author:  [@originalsouth](https://discourse.julialang.org/u/originalsouth)
#### Post date: [September 9, 2020, 6:20am UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/8 "2020-09-09T06:20:57Z")
Indeed placing `const N = length(ARGS)==1 ? parse(Int64,ARGS[1]) : 1000` fixes the performance! Thank you!
---
### Author:  [@lungben](https://discourse.julialang.org/u/lungben)
#### Post date: [September 9, 2020, 6:39am UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/9 "2020-09-09T06:39:45Z")
Global variables are a bad practice and should be avoided in any programming language.
For the rare occasions they are really needed the `Ref` syntax is available in Julia.
Even if there would be ways to generally speed up global variables in Julia, this would take up valuable time from the core devs and encourage bad programming styles.
---
### Author:  [@paulmelis](https://discourse.julialang.org/u/paulmelis)
#### Post date: [September 9, 2020, 12:24pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/10 "2020-09-09T12:24:40Z")
> [@Henrique\_Becker](#):
>
> Do you mean: “we could have non- `const` fast globals in the future, their only restriction is that they cannot change type (but they could change value)”? We kinda already have that, you just need to make a global `const N = Ref(parse(Int64,ARGS[1]))` (the value is accessed by `N[]` and can be changed by `N[] = new_value` ).
> [@lungben](#):
>
> Global variables are a bad practice and should be avoided in any programming language.
> For the rare occasions they are really needed the `Ref` syntax is available in Julia.
> Even if there would be ways to generally speed up global variables in Julia, this would take up valuable time from the core devs and encourage bad programming styles.
Ironically, I would consider the `Ref` workaround shown above also bad programming style (more so as it is caused by non-const untyped globals being so slow).
And the only time use of global variables is really a bad practice is if you write code using globals where the code might get reused as a module, in which case the globals can cause trouble. For standalone scripts whose code will never get reused it’s no issue. The OP’s example of initializing a global variable `N` _in a standalone script_ is valid and it’s a shame that this have to be avoided due to performance consequences.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [September 9, 2020, 1:07pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/11 "2020-09-09T13:07:07Z")
I am all for people adopting good programming practices and avoiding bad programming practices. I just hope they understand why they are considered either, instead taking advice that is never absolute as an absolute rule.
---
### Author:  [@paulmelis](https://discourse.julialang.org/u/paulmelis)
#### Post date: [September 9, 2020, 1:39pm UTC](https://discourse.julialang.org/t/why-do-global-variables-impact-performance-so-badly/46293/12 "2020-09-09T13:39:22Z")
I guess absolute statements elicit absolute responses 😉