Hashtables and Memory Leaks

HydraRancher

Truth begins in lies
Reaction score
197
Definitely NOT (It ruins my trigger as well, seems that location isn't exist). Anyway I have changed save location to save real(LocX and LocY) instead and it works efficiently. (I don't really care much about leak but this force me to use real :p)



This may explain the reason why.

Believe me, use GetLocationX and GetLocationY is better.


This may explain the reason why you're doing it wrong? :p

I can't believe you that using LocX and LocY is better without anything more than you saying so.
 

KaerfNomekop

Swim, fishies. Swim through the veil of steel.
Reaction score
613
So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
I thought of just doing something like
Code:
call RemoveLocation(LoadLocationHandleBJ(GetHandleIdBJ(GetTriggerUnit()), udg_LocationInteger, udg_Hashtable)

Would that work?
 

Romek

Super Moderator
Reaction score
964
> When ever I've saved points into hashtables I save them directly. Like saving (Position of (Triggering Unit)). But does that create leaks?
It's not quite a leak, as you can still reference the location and remove it afterwards. When you no longer need that location, load it from the hashtable and use RemoveLocation. Leaks are handles that are still in memory that you're not using and have lost reference to.

> I believe that's what Romek means.
Yup.

> Believe me, use GetLocationX and GetLocationY is better.
I don't believe you.

> So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
TempPoint can point to any single location. If you store that location into a hashtable, you could reference it either by loading it from the hashtable, or using TempPoint (it would be the same location, regardless). You could set TempPoint to some other location if you wanted, and still be able to reference that first location through the hashtable (though TempPoint will now be a different location). Neither of these locations would be leaks until they were no longer being used. Using RemoveLocation(udg_TempPoint) removes whatever location TempPoint is set to. However, note that handles are pointers, so that'd also make all other references to that location null (such as ones that have been saved into hashtables), so you wouldn't be able to load that same location from a hashtable after. Basically, only remove locations once you're done with them. The actual location, that is. Not necessarily the variable.

> Would that work?
Well, yes. Why would you ever want to do that though? o_O
 

KaerfNomekop

Swim, fishies. Swim through the veil of steel.
Reaction score
613
> When ever I've saved points into hashtables I save them directly. Like saving (Position of (Triggering Unit)). But does that create leaks?
It's not quite a leak, as you can still reference the location and remove it afterwards. When you no longer need that location, load it from the hashtable and use RemoveLocation. Leaks are handles that are still in memory that you're not using and have lost reference to.

> So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
TempPoint can point to any single location. If you store that location into a hashtable, you could reference it either by loading it from the hashtable, or using TempPoint (it would be the same location, regardless). You could set TempPoint to some other location if you wanted, and still be able to reference that first location through the hashtable (though TempPoint will now be a different location). Neither of these locations would be leaks until they were no longer being used. Using RemoveLocation(udg_TempPoint) removes whatever location TempPoint is set to. However, note that handles are pointers, so that'd also make all other references to that location null (such as ones that have been saved into hashtables), so you wouldn't be able to load that same location from a hashtable after. Basically, only remove locations once you're done with them. The actual location, that is. Not necessarily the variable.

Doesn't that do this?
 

HydraRancher

Truth begins in lies
Reaction score
197
I believe he meant load it from the hashtable like Set TempPoint = Load 0 from Key(Triggering Unit) in Hashtable.
 

Bankde

Member
Reaction score
20
Sorry for the offtopic post, just reading this and had to quote Romek
> Believe me, use GetLocationX and GetLocationY is better.
I don't believe you.

LoL thank though. Anyway may I have your reason (Romek Reason)?
I have my own reason that real will not leak.

I believe Romek have better and there maybe sth I should learn.
 

HydraRancher

Truth begins in lies
Reaction score
197
Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.
 

Romek

Super Moderator
Reaction score
964
> Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.
It's not really about using one value instead of two.

In JASS, using two reals is always preferred over a location (with a minor exception of checking terrain height). Locations in general are pretty much GUI-exclusive, because of how inferior they are compared to using coordinates directly. Coordinates can be easily manipulated mathematically (whereas locations can't), and using them gives you the flexibility of easily doing whatever you want with positions. Almost all location functions (such as polar offset) first convert to reals, then do whatever they need to do, before converting the resulting reals back into a location. Then there's also the leak to clean up. Reals are, in theory, much more efficient and flexible than locations.

However. This is GUI, not JASS. There's a lot of support for locations compared to coordinates, which makes using reals quite difficult, and will probably result in converting them to a location quite often (or result in using relatively complicated custom scripts - though if you can do that, you shouldn't even be using GUI). There can also be quite a lot of maths involved with reals, and I'm sure you all know that anything past simple arithmetic maths is a pain to do in GUI.
Besides all of that, GUI is horrible efficiency-wise anyway, and there's nothing at all you can do about that. It's pointless to go out of your way to make a small efficiency tweak when every if-condition block (amongst many other actions) you use set that back in the opposite direction again. It's not a game-breaking difference, but it's more than enough to warrant prioritizing readability and usability over efficiency. Just stick to what GUI is best at: simple, English, readable* code.

Edit: You specifically mentioned using GetLocationX and Y. You're not accomplishing anything there, as you're using both locations and reals.
 

NeuroToxin

New Member
Reaction score
46
I love how you reply Romek, Your replies are always the best.

@This topic. All Romek was saying without reading his wall of text like I just did, is that GUI was made for Locations, (Not GUI, but it was made to USE locations) and JASS was used to make reals, so that way you can basically use natives, (no known source, just what I think) to efficientize it. (I'm using my word again)
 

Bankde

Member
Reaction score
20
> Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.
It's not really about using one value instead of two.

In JASS, using two reals is always preferred over a location (with a minor exception of checking terrain height). Locations in general are pretty much GUI-exclusive, because of how inferior they are compared to using coordinates directly. Coordinates can be easily manipulated mathematically (whereas locations can't), and using them gives you the flexibility of easily doing whatever you want with positions. Almost all location functions (such as polar offset) first convert to reals, then do whatever they need to do, before converting the resulting reals back into a location. Then there's also the leak to clean up. Reals are, in theory, much more efficient and flexible than locations.

However. This is GUI, not JASS. There's a lot of support for locations compared to coordinates, which makes using reals quite difficult, and will probably result in converting them to a location quite often (or result in using relatively complicated custom scripts - though if you can do that, you shouldn't even be using GUI). There can also be quite a lot of maths involved with reals, and I'm sure you all know that anything past simple arithmetic maths is a pain to do in GUI.
Besides all of that, GUI is horrible efficiency-wise anyway, and there's nothing at all you can do about that. It's pointless to go out of your way to make a small efficiency tweak when every if-condition block (amongst many other actions) you use set that back in the opposite direction again. It's not a game-breaking difference, but it's more than enough to warrant prioritizing readability and usability over efficiency. Just stick to what GUI is best at: simple, English, readable* code.

Edit: You specifically mentioned using GetLocationX and Y. You're not accomplishing anything there, as you're using both locations and reals.

That's the main reason. I agree that using GUI is not suitable with real. Location is really better here.

Thank Romek, again. >_<
 
General chit-chat
Help Users
  • No one is chatting at the moment.
  • Ghan Ghan:
    Still lurking
    +3
  • The Helper The Helper:
    I am great and it is fantastic to see you my friend!
    +1
  • The Helper The Helper:
    If you are new to the site please check out the Recipe and Food Forum https://www.thehelper.net/forums/recipes-and-food.220/
  • Monovertex Monovertex:
    How come you're so into recipes lately? Never saw this much interest in this topic in the old days of TH.net
  • Monovertex Monovertex:
    Hmm, how do I change my signature?
  • tom_mai78101 tom_mai78101:
    Signatures can be edit in your account profile. As for the old stuffs, I'm thinking it's because Blizzard is now under Microsoft, and because of Microsoft Xbox going the way it is, it's dreadful.
  • The Helper The Helper:
    I am not big on the recipes I am just promoting them - I use the site as a practice place promoting stuff
    +2
  • Monovertex Monovertex:
    @tom_mai78101 I must be blind. If I go on my profile I don't see any area to edit the signature; If I go to account details (settings) I don't see any signature area either.
  • The Helper The Helper:
    You can get there if you click the bell icon (alerts) and choose preferences from the bottom, signature will be in the menu on the left there https://www.thehelper.net/account/preferences
  • The Helper The Helper:
    I think I need to split the Sci/Tech news forum into 2 one for Science and one for Tech but I am hating all the moving of posts I would have to do
  • The Helper The Helper:
    What is up Old Mountain Shadow?
  • The Helper The Helper:
    Happy Thursday!
    +1
  • Varine Varine:
    Crazy how much 3d printing has come in the last few years. Sad that it's not as easily modifiable though
  • Varine Varine:
    I bought an Ender 3 during the pandemic and tinkered with it all the time. Just bought a Sovol, not as easy. I'm trying to make it use a different nozzle because I have a fuck ton of Volcanos, and they use what is basically a modified volcano that is just a smidge longer, and almost every part on this thing needs to be redone to make it work
  • Varine Varine:
    Luckily I have a 3d printer for that, I guess. But it's ridiculous. The regular volcanos are 21mm, these Sovol versions are about 23.5mm
  • Varine Varine:
    So, 2.5mm longer. But the thing that measures the bed is about 1.5mm above the nozzle, so if I swap it with a volcano then I'm 1mm behind it. So cool, new bracket to swap that, but THEN the fan shroud to direct air at the part is ALSO going to be .5mm to low, and so I need to redo that, but by doing that it is a little bit off where it should be blowing and it's throwing it at the heating block instead of the part, and fuck man
  • Varine Varine:
    I didn't realize they designed this entire thing to NOT be modded. I would have just got a fucking Bambu if I knew that, the whole point was I could fuck with this. And no one else makes shit for Sovol so I have to go through them, and they have... interesting pricing models. So I have a new extruder altogether that I'm taking apart and going to just design a whole new one to use my nozzles. Dumb design.
  • Varine Varine:
    Can't just buy a new heatblock, you need to get a whole hotend - so block, heater cartridge, thermistor, heatbreak, and nozzle. And they put this fucking paste in there so I can't take the thermistor or cartridge out with any ease, that's 30 dollars. Or you can get the whole extrudor with the direct driver AND that heatblock for like 50, but you still can't get any of it to come apart
  • Varine Varine:
    Partsbuilt has individual parts I found but they're expensive. I think I can get bits swapped around and make this work with generic shit though
  • Ghan Ghan:
    Heard Houston got hit pretty bad by storms last night. Hope all is well with TH.
  • The Helper The Helper:
    Power back on finally - all is good here no damage
    +2
  • V-SNES V-SNES:
    Happy Friday!
    +1
  • The Helper The Helper:
    New recipe is another summer dessert Berry and Peach Cheesecake - https://www.thehelper.net/threads/recipe-berry-and-peach-cheesecake.194169/

      The Helper Discord

      Members online

      No members online now.

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top