local method variable or global class ?
-
i was wondering if it's best to use a global variable or a local one which is each time allocated? for exemple in a paint event i would think it's better to create the brush and graphics handle before (eg in constructor) but in exemple code i've seen them in the paint method so they are allocated each time a paint is occured...
It would be more efficient to allocate in the constructor. You are anyway going to use it everytime a paint occurs, you might as well cache it. And because Brush and Graphics handles will have unmanaged resources, it would be more efficient to get them once and hold on to them rather than acquiring and releasing them every time. That said, the .NET GC is very good at cleaning up objects that are destroyed soon after creation, so you might want to measure it up using a profiler. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
It would be more efficient to allocate in the constructor. You are anyway going to use it everytime a paint occurs, you might as well cache it. And because Brush and Graphics handles will have unmanaged resources, it would be more efficient to get them once and hold on to them rather than acquiring and releasing them every time. That said, the .NET GC is very good at cleaning up objects that are destroyed soon after creation, so you might want to measure it up using a profiler. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
It think this might not be entirely accurate. Caching the Graphics-handle might get you into serious trouble, as the Paint-Event is triggered very often without giving you the slightest hint WHY it occurred. Lets say you have a window which was just resized. You still have the Graphics handle and start drawing. Everything will look ok at first glance, but you will soon notice that everything outside your original "drawing pane" is not being drawn. Lines end, circles appear as arcs ... and you have no clue what is going wrong. Its quite simple: You are still holding onto an outdated Graphics-Object. You should only draw when told by WM, anyway, so in OnPaint you imho SHOULD assume that major changes might just have occured. This means: Reassign the graphics object and redraw the invalidated rectangle (or the whole shebang, if you need to). Cheers Sid
-
It think this might not be entirely accurate. Caching the Graphics-handle might get you into serious trouble, as the Paint-Event is triggered very often without giving you the slightest hint WHY it occurred. Lets say you have a window which was just resized. You still have the Graphics handle and start drawing. Everything will look ok at first glance, but you will soon notice that everything outside your original "drawing pane" is not being drawn. Lines end, circles appear as arcs ... and you have no clue what is going wrong. Its quite simple: You are still holding onto an outdated Graphics-Object. You should only draw when told by WM, anyway, so in OnPaint you imho SHOULD assume that major changes might just have occured. This means: Reassign the graphics object and redraw the invalidated rectangle (or the whole shebang, if you need to). Cheers Sid
I wasn't talking about the Graphics object passed to Paint(), I know it is not supposed to be cached and reused. I was talking about other Drawing related objects like Brushes. [EDIT]My bad, it looks like I did say that for Graphics too, I didn't realise he was talking about the Graphics object specifically [/EDIT] Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
I wasn't talking about the Graphics object passed to Paint(), I know it is not supposed to be cached and reused. I was talking about other Drawing related objects like Brushes. [EDIT]My bad, it looks like I did say that for Graphics too, I didn't realise he was talking about the Graphics object specifically [/EDIT] Regards Senthil _____________________________ My Blog | My Articles | WinMacro
Yeah, I wouldn't recommend holding onto any unmanaged handles for longer than the current paint event. Since there are limits to the number of handles (of any type) that can be checked out system-wide, its considered good practice to not hold onto them for any longer than you absolutely need to. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Yeah, I wouldn't recommend holding onto any unmanaged handles for longer than the current paint event. Since there are limits to the number of handles (of any type) that can be checked out system-wide, its considered good practice to not hold onto them for any longer than you absolutely need to. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
But wouldn't the cost of acquiring the unmanaged resource (most probably through transitioning to unmanaged code) and releasing it warrant caching? And we are just caching a few handles, do you think that would make the system run out of handles? Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
But wouldn't the cost of acquiring the unmanaged resource (most probably through transitioning to unmanaged code) and releasing it warrant caching? And we are just caching a few handles, do you think that would make the system run out of handles? Regards Senthil _____________________________ My Blog | My Articles | WinMacro
The cost of allocating those resources is negligable. You're not gaining that much of a perfomance benefit by caching it. Also, if you cache the handle, then change the screen resolution or color depth, the handle is no longer valid for drawing. No, just caching a few handles will not run the system out of resources. But it requires you to keep track of them for the duration of the application session. Just about everything in Windows has a handle attached to it, some even use thousands at a time. The performance benefit is just not worth the extra overhead of caching them. Allocate it, use it, free it... Would you open a database connection and hang onto it for the duration of your app? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
The cost of allocating those resources is negligable. You're not gaining that much of a perfomance benefit by caching it. Also, if you cache the handle, then change the screen resolution or color depth, the handle is no longer valid for drawing. No, just caching a few handles will not run the system out of resources. But it requires you to keep track of them for the duration of the application session. Just about everything in Windows has a handle attached to it, some even use thousands at a time. The performance benefit is just not worth the extra overhead of caching them. Allocate it, use it, free it... Would you open a database connection and hang onto it for the duration of your app? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
I actually would. Prior to ADO.NET, we used to maintain our own database connection pool and the application ran significantly faster. Same concept as thread pools. But yeah, I do agree with your point though, it might not be worth caching those objects. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
I actually would. Prior to ADO.NET, we used to maintain our own database connection pool and the application ran significantly faster. Same concept as thread pools. But yeah, I do agree with your point though, it might not be worth caching those objects. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
Even though it's expensive to open a database connection, it's considered extremely poor practice to open a connection and hang onto it for the duration of the app. Since SQL Server connection licenses are ($)expensive, and there are a limited number of them compared to the number of users using the system, it's always good form to create the connection and hold it open only for as long as absolutely necessary. Remember, the number of SQL connections available are not specific to one application or database, they're available for the entire server! So, depending on the situation, it's entirely possible to support 10,000 users on 500 licensed connections, using many different database applications. Think about it...How many user would be using the system at any one time? How many of them are going to be accessing the databases at exactly the same time? What kind of money would your customer like to spend? It's always as little as possible, correct? So why would your customer spend the money on 10,000 licenses when only about 1,000 of them, max, are going to be using the system at any one time? Starting to see how "Grab it, use it, release it" is considered "best practice"? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Even though it's expensive to open a database connection, it's considered extremely poor practice to open a connection and hang onto it for the duration of the app. Since SQL Server connection licenses are ($)expensive, and there are a limited number of them compared to the number of users using the system, it's always good form to create the connection and hold it open only for as long as absolutely necessary. Remember, the number of SQL connections available are not specific to one application or database, they're available for the entire server! So, depending on the situation, it's entirely possible to support 10,000 users on 500 licensed connections, using many different database applications. Think about it...How many user would be using the system at any one time? How many of them are going to be accessing the databases at exactly the same time? What kind of money would your customer like to spend? It's always as little as possible, correct? So why would your customer spend the money on 10,000 licenses when only about 1,000 of them, max, are going to be using the system at any one time? Starting to see how "Grab it, use it, release it" is considered "best practice"? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
I do agree that for some resources, the "Grab it, use it, release it" philosophy works great. However, I don't see database connections as one such resource. In fact, ADO.NET provides connection pooling automatically (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconConnectionPoolingForSQLServerNETDataProvider.asp[^]). Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
I do agree that for some resources, the "Grab it, use it, release it" philosophy works great. However, I don't see database connections as one such resource. In fact, ADO.NET provides connection pooling automatically (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconConnectionPoolingForSQLServerNETDataProvider.asp[^]). Regards Senthil _____________________________ My Blog | My Articles | WinMacro
Don't take my word for it! Start asking around about what is considered best practice for database connections. It is true that ADO.NET does do connection pooling, but it does the very same thing that I've talked about. The connection to the server is closed, releasing the connection license on the server until ADO.NET decides it needs to be opened again. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome