@@shreehari2589I think they mean pass the global_var as a parameter like def function(local_var): and then pass global_var when you call the function
can you explain why we should avoid global variable? I am new to python and been seeing alot of this information, but quite unsure how to workaround on that.
@@novianandrian global variables sow the seeds of terribly bad practices in learners, and experts never use them anyway. the reason why is because new learners dont fully grasp what a function is. it isnt code you just put under a `def` block because thats what you think you are supposed to do. its not even just "repeatable" code. a function is essentially a "sub"program. suppose you are making a library, and someone imports your functions. that function is a black box to them, and they cant see that it wants to use "x" from the global scope. if the function tried to, and they actually did have an "x" in their global scope, even though they didnt know that was part of the use case, they would almost certainly run into inaccurate outputs with absolutely zero clue as to where said output was coming from, and literally no possible way to debug that. but thats not just to say that globals are bad only in the context of libraries, using global variables like this is genuinely harmful no matter what. they direct your code into a very specific architecture which is completely unmaintainable, unreadable and harder to debug. they promote misconceptions on what functions are and how they are meant to interact with a program. and you will never, ever be able to advance beyond basic scripting while you still maintain this habit, because projects that are better formatted in multiple files are practically a nightmare to debug or expand when even a few globals are being thrown around between scopes and files. in short, one of the biggest things i would tell anyone at this point in their journey to learn programming is to make sure that in every circumstance your functions are able to be run on their own. all of the information they need to function fully should be passed in through parameters. if you feel as though you cant do this for your specific case, it may be a sign that your code architecture is wrong, as I have never had that actually be the case in over 6 years, nor have I heard of anyone who has.
@@novianandrianbecause it creates a lot of dependencies for your function, and makes the code less organized either pass it as a paramater, or create a class and make the function a member of the class using it for constants is fine not using global variables is a good practice for all programming languages
@@the_cheese_cultist when you have code that might need constant change or update don't global variables make everything faster? Im doing my capstone college class and im working on a website that deals with different aspects of CSV data surveys. and i approached it with the mindset of "hey making everything global makes it easier to edit later. (side not it was inherited from last year and the whole approach the other team started with was a mess so we could only focus on refactoring.)(we worked with ruby on rails )
@@stilyandimitrov39 I'm gonna need more info to give you an opinion, but there are many sources online about good coding practices, avoiding globals included, that can explain everything better than a RU-vid comment.
I always get annoyed when looking at others' Python code and see something like: "object1 = object2". I've even seen inside a function something like: c_time = time.time() current_time = c_time Please explain to me why anyone would do something that seems so redundant?
No, Python does not check locally then globally. Python knows what is local and what is global at compile time. The difference is that globals is a dict, locals is an array, so local access is direct indexing vs dict look up. You can have a look at disassembly, when python determines the variable is local it uses LOAD/STORE_FAST, vs LOAD/STORE_NAME. The name is quite explicit which is more efficient.
@@tobias8951 Python is first compiled into bytecode (thats the .pyc that you might see next to the .py file) and the bytecode is then interpreted by the python interpreter. You can have a look at the bytecode with the dis module. Do "from dis import dis", then pass your sample code as a string to the function dis and print the result. The actual disassembly will vary from version to version, but you should have a "
I believe this is incorrect, any recent (python 3 and up) will emit a LOAD_FAST for locals (like ans and i) but a LOAD_GLOBAL for nonlocal, non-cell variables (like global_var). The speed difference between LOAD_FAST and LOAD_GLOBAL is pretty much negligible, especially with the adaptive opcodes in newer versions where most of these have faster, adaptive versions.
Yes this is correct. Also corroborated by the fact that the variable scope (aka what namespace python will search for a given variable) is determined at compile time before the interpreter will execute the byte code. Mcoding has a great video about this
there's the `global` keyword, or `nonlocal` for nested functions instead of creating local_variable, you can just declare `global global_variable` at the top of the function
You have completely missed the point of the video. Hint: adding "global global_variable" at the top of the function doesn't change the bytecode at all. The whole (bad as it might be) point of the video is that accessing a global variable from the inner loop takes more time than loading the global variable into a local variable first.
I prefer passing the required values into the function as arguments. If I need to reuse a function in a different script, I know by the function signature exactly the function requires to run.
@@l3gacyb3ta21 I wouldn't say it's strictly better, it's a tradeoff - because to get faster python you have to decrease the readability by making your code appear a little more complex. You should choose Python when code readability/understandability is important and performance isn't important, because that is what the language is designed for. That's why it's a really good language for one-off quick scripts. But if you are in a problem space where performance is valuable, it's nice to use a language that's really designed for that from the get-go. Where you can actually use the language's nice features without surprise performance problems. That being said, sometimes you inherit a codebase that's already in Python and performance may become an issue so sometimes you have to choose lower code readability for better performance.
This is not true. Variable scoping is done at compile time (yes, Python has one), not at runtime. It's actually the only complex thing Python compiler does. You can look through the related data structures using the symtable module. It's also visible if you use dis.dis on each version of the function - one will have LOAD_FAST op, the other will use LOAD_GLOBAL. It's predetermined.
It's predetermined but it doesn't mean it has the same cost. Lookup in local scope is faster for many reasons - it can be stored more efficiently, you can have more faith in what you are dealing with etc. For example, if you are dealing with something in outer scope, there are no guarantees about the value assigned to the variable as it may be changed in some other part of the code and global lookup has to be used to ensure that you are using proper value at the time you want to access it. If you copy the global value to a locally scope one, you can avoid that lookup as it is "detached" from its old variable. I don't know how lookups are managed for collections but if they are not explicitly copied, then I would assume they are stilled handled through global lookup rather than a local one based on the same problems with it being stored at a global level.
@@viCoN24 Your reasons are also wrong. The object under reference is stored the same way no matter if it's local or global. "Outer scope" and "global" are two different things, but whether you have "guarantees" about the referenced value or not is irrelevant - cPython has no JIT. It has global interpreter lock, so the dereference doesn't have to do nich Apart from finding the actual memory address. I would invite you to profile this in an actual code, where the local scope has just as many items as the global one.
I think I missed your point. Thanks for the explanation! You focused on the underlying mechanism where it's still one operation rather than two lookups. I don't know how these operations are performed by CPython but one is clearly faster than the other so I tried to provide some reasoning behind it but it's true that GIL simplifies the situation. In principle the lookup resolution behaves as author explained even though the interpreter is able to scope it internally to decide on the proper operation rather performing dynamic lookup and failing at runtime when variable is not found. You are right that it's only one operation but whether it's assigned that one operation or the other is decided in the fashion described by the video maker.
A rule of thumb I have is to maximize clean encapsulation like in pure functional programming. Everytime I want to use a global state, I pass that state by reference. This is so that you know which function is modifying what at any given time via the function calls. It's really hard to spot any modification or references to global state if you directly refer to it within a method.
The same point applies to attribute lookup on imported modules. For example, you can assign imported function to a local variable to avoid an expensive lookup. Let's say you use "math.sin" in a loop. Every time you call it, you perform a lookup on "math" module for "sin" attribute before calling that function. If you assign "sin = math.sin", you get rid of that unwanted lookup from "math" module and your loop with local "sin" will be faster. If you have a function that creates a lot of objects, you might also want to assign the class locally to also avoid global lookup for the same reason. If you find it interesting, you are dealing with some problem that Python might not be the best language to solve it in. Still, if you have to resort to those optimizations, it's at least nice to know about them.
I think it is much better to make function with this 'global varible' as argument. Using global variables in functions is bad practise, because it makes functions less portable (you can't just take this function and place it in another program or file, because it may doesn't have this variable in it)
Better - when writing non trivial programs, it's often hard to avoid globals - unless you want to make the call graph a complete mess. If you're determined to kill all globals, you might want to malloc() a singleton (a struct) containing all of them (so you can re-enter the function without side effects) and pass it down all the way - even if you don't use it. That way if you change a function so it requires the use of such singleton, it's there. You might get a few warnings, but it works - and it makes maintenance less of a pain in the neck. BTW, always initialize your global vars in a separate function. You might be in for a surprise if you call it multiple times.
In other langs, this fixes race conditions, as the code no longer assumes the variable won't be mutated. The program no longer has to load from heap every iteration, since the value is already on the stack
This is one of the reasons, yes. C and C++ are, by default, pass by value. That means when you pass arguments to a function the values are copied for the function to use. Passing a pointer is still technically pass by value, but the value being copied is the *address* of the data; rather than the data itself. This allows you to save memory for larger variables (e.g., a big struct or a class). It also allows you to modify the original data, since you're being given a pointer to it rather than a copy of it. Note that C++ has references, which are often used over pointers because they are safer (but are very very similar). If you're in C++, default to using references unless you have a reason to use a pointer (e.g., so you can call C functions). For functions which are taking a pointer/reference to save time on copying data, you'll often see `const MyLargeDataType *mldt` or `const std:: string &str`. The `const` part signifies that the data being pointed to will never be modified by the function. Something to keep in mind also is that, for pointers, the following two are not the same: `const int *a`, `int *const b`. Here, `a` can be re-assigned to a new address of another `const int`. However, the contents at the address cannot be changed. For `b`, the contents at the address can be changed, but the address it actually points to cannot be changed. Here are some examples: ``` int c = 123, d = 456; const int *a = &c; int *const b = &c; a = &d; /* okay, we can change where it points */ *a = 789; /* not okay, we can't change the data it ponts to */ b = &d; /* not okay, we can't change where it points */ *b = 1011; /* okay, we change the data it points to */ ``` Note that in C++, all references are `const` (the address they point to cannot be changed), but you can still modify the data they point to so long as the type is not marked as `const`.
@@whirvis Thanks for the explanation. I'm trying to learn C, and pointers are a bit confusing to me, particularly when and why to use them. As I understand it: int a; //declares a variable containing a value. int *b; //essentially declares two variables, one contains a value, the other, an address. *b = 123; //contains a value b = &a; //contains an address void Function(int *c){} //expects an address. Call like this: Function(&a);
@@MortonMcCastle int a; // designates enough memory to store an int but doesn’t say what int to store int *b; // designates enough memory to store an address which, when dereferenced, should point to memory that stores an int (should not be thought of as declaring two variables because it’s only declaring memory for the pointer, not for any actual int value) *b = 123; // is a very insidious bug because you’re modifying data at a random memory location because you never initialized b with a valid pointer so it’s interpreting whatever bits happened to be at that spot in memory before as a memory address. This is the kind of bug that hackers exploit to gain escalated privileges to systems. b = &a; // b is now a pointer to a, so now it is safe to do *b = 123 which is equivalent to a = 123
The best optimization trick in this case is not bringing the global_var into the local scope as local_var. It is going back to 5th grade and learning that you can simplify this function to def func(): return global_var * 1000 * 1001 / 2 (**exceptionally hard to do**)
@@revimfadli4666yeah, it’s probably a fine optimization if your program is just a counter multiplying by a global, but it is woefully insignificant in the scale of any program larger. Or, if your program is just a big loop, use PyPy. I remember hearing that it’s better at this stuff.
Using Global variables is not good, unless they are constants. If you need a value [especially a variable one] it should be passed as a parameter to the function, so that the function always have the same exact behavior when it is passed the exact same parameters. makes them predictable and individually testable.
If you want fast code, don't use python. No, don't optimize your python code, write anything that has to be fast in C and use pyhton for things that don't have to be fast.
Functions can take parameters Just create function with parameter Then pass variable as parameter when you call function It virtually as your solution but it is standard do that this way.
This problem is the same in every interpreted programming language ( it doesn't affect performance on compiled langs cuz this only happends while compiling, not when running )
Thanks. Yes and no about this method, Python is about writing understandable code, only big picture optimizations are needed (general algorithm). If you value even 10% loop speed increase, beter switch to C, Rust or Cython that prt of code or
But in order to assign the new local variable with the value of the global variable, wouldn’t the function still look within itself for local first, then global?
This does not reassign the local variable to the global correct, like it doesn’t change the global from what it was originally to what it is after the local function is done? Sorry super new here to python and coding.
@@thesleepingforest8929 It does, assigning the global_var to local_var creates kinda like a pointer so every time you reference the local_var it points to the global one and edits the global_var Unless I'm wrong.
@@nytherit depends on the data type. If it is a string, int, double it creates a copy. If it's a list, set, ect then changing the local will affect the global.
in pretty much every language you will have a performance penalty by using global instead of local var global vars are in different part of memory than your local vars, which are on a stack. also usage of local vars can be optimized (to a constant in this case) - if you're not passing a reference to it, nothing is going to modify it. global variables on the other hand, compiler would need to know that your global var is not used by any of the functions down the call stack. that's quite simple in this case, but not in general and therefore it compiles to a read from mem on every access
@@tajkrisnot exactly… in C for example the only cost related to global vars is dynamic allocation, ie creation of global variables at runtime, ie calling malloc. Any globals defined statically have already been loaded into memory at program start and are already allocated. Memory access always has a speed of O(1) so every memory access has the same speed. so no… global variables aren‘t intrinsically slower at least in c and c like languages.
@@spookycode As a matter of fact, creating and destroying a stack frame takes the majority of the performance overhead of calling a function. Those creating VMs usually implement it as a switch() instead of a table of function pointers - just to avoid function call overhead.
@@drewsarkisian9375 There's nothing wrong with using Python - but accept that "optimizing" it is useless. If you want raw performance, accept you have to use another language.
It would be more optimal to calculate the answer rather than iterate. The sum from 1 to N is N*(N+1)/2. So your code could be changed to global_var * N * (N+1)/2.
@@ZeroSpawn what are you saying? if you want a function to access a variable declared at a global scope you can add the line "global variable_name" below the function definition to make it accessible without redefinition
Adding the global keyword specifically tells Python to WRITE to that global variable if you try to assign to that name instead of the local namespace, so if you want to ensure that your function code can't modify the global variable, that's a bad way to go.
A) Calling it in the first place isn't unoptimal, the extra instruction to look outside the scope is completely irrelevant. B) you can use the global parameter. C) you should be passing it in instead if you're really worried about optimization. Because you want to avoid an instruction to look outside the local scope you force it to declare another variable in the existing stack, how is that more optimal?
I didn't code in python for quite some time but my guess is, that it only allocated memory once and then keeps a close reference to that value, similar to how the register keyword in C works
May I know how you have produced the graph of performance. I would highly appreciate if you can create shorts or a detailed video on this. I would like to test few other functions and Optimizations for personal use. Thanks in advance.
I got a question, how would you switch an item between two dictionaries or lisits? Lets say an person between "working" and "on break" lists? One idea i had was this. People = [people names here] Working = [people:] On break=[:people]
What I understood is to make that variable in local scope so as to prevent checking for the golabal variable each and every time. This reduces the time complexity
this optimization doesn't change time complexity, for that function it is O(n). time complexity refers to how well an algorithm scales when the amount of input data is increased. this optimization just reduces cpu cycles required to access the variable.
the main i see here is the for loop, when at that scale of iterations i'd look at a different way to implement that section of code first, for instance doing that specific part in a more optimized language
That's not the only reason to use a local variable inside the function. An arguably more important reason is that it's bad practice for functions to modify global scope. This is because other code might also access the global variable. The global variable's value is unpredictable because we don't know how often the function is called, or under what circumstances it will get called. This makes it hard to reason about the behavior of the program.
@@joergsonnenberger6836 ah, you're right, I misread that. However, there is still some risk that some other code will modify the global variable, and that will change the behavior of the function.
Don't do that. First, you should avoid using a global variable. But let's assume you really need to. Then use the "global" keyword inside of you scope to indicate the interpreter to look directly into the global scope ti retireve the variable. You should also checkout the "lonlocal" keyword, having the same effect but instead of targeting the global scope, it targets the direct upper one.
Man being new to Python and new to coding just sounds like an awful time. Coming into python with years of statically typed OOP these are just things I do automatically lol
This is the sort of detail that creates training warts that end up in other code often in other languages and people don’t remember why they did it 5 tests down the line when the implementation changes. I avoid these sorts of “optimizations” unless o have no other choice. Even if said choice is writing in another language.
Replace the loop with something non-trivial and it can't guarantee that the module scope object binding doesn't change. Similar to how a C compiler could have to load the same pointer again and again as if it can't proof that it wasn't changed.
