Zugg Software :: View topic - Variable access by "reference" vs by "value"

Posted: Wed Jun 16, 2010 7:47 pm

In the last update I fixed a problem with various functions like %additem, %delitem, etc that were modifying the list/table passed in the second argument. So I changed them so they create a copy of the table to return.

Problem with this is that it will slow down scripts that just use %additem because it allows duplicates. You don't really want a line like:

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Sounds like quite the elegant solution. Good stuff!

Edit: Nvm.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Will it be possible to use this on nested lists as is possible with #additem?

Such as: #call %additem( "item", list.item) or #call %additem( "item", db.key)

Instead of #var list.item %additem( "item", @list.item) or #addkey db key %additem( "item", @db.key)

Posted: Fri Jun 18, 2010 2:19 am

Yes. Give it a try, it should already work.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Oh, I did not realize that this was already put in. I'll give it a go and give you an update.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Alright, so a couple issue. If you feed it a key and it doesn't exist, then it won't create it. Additionally, if the key does exist, but there's nothing in it, then it will treat it as a null item. This script should illustrate what I'm talking about.

Moved to: http://forums.zuggsoft.com/forums/viewtopic.php?t=35355

I would think, ideally, that %additem( "item", ref) would act the same as #additem, but with duplicates.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

It also appears that #call %delitem( "item", ref) is slower than #delitem even when the list has no duplicates; I would think the opposite would be true. Assuming a list with no duplicates, #delitem will search from the beginning to the end of the list every time, while %delitem would stop after finding an item. Am I making any erroneous assumptions here? I'm not quite sure what the difference between a command and a built-in function is.

Also, sort of off the issue between %delitem and #delitem, but I'm surprised to see that the unsorted tests are faster. Is this due to the list being re-sorted after each item is deleted? Seems to me that if you remove an item from a sorted list, that it should still already be sorted. Furthermore, if #delitem is going through a sorted list, finds an item, deletes it, and then the next item doesn't match, it would be logical that there's no more matching items in the list, so it should stop. Again, that's me making assumptions on top of assumptions, but I figured I'd throw some of my thoughts out there.

Here's the script I used to test:

code:

Posted: Fri Jun 18, 2010 4:46 pm

Thanks for the script. That's just the kind of additional benchmark that I was planning to do next week.

The difference between #delitem and %delitem definitely looks to be odd. #delitem *should* be faster because it has to do an additional "ismember" to determine if there is more than one matching item that needs to be deleted. But it's possible that %delitem is still converting the table to a string value somewhere along the line even though you are using #call and the new "by reference" syntax. Definitely something I'll look into.

The reason the Sorted #delitem is slower than unsorted is that when a string list is sorted, CMUD needs to maintain an additional binary search tree for the items in the list. Deleting an item from a binary search tree requires the tree to be rebalanced sometimes. I haven't looked at the algorithm used for this in any real detail, but that's a small overhead that the unsorted list doesn't have. The difference between the two is small enough that I'm not really worried about this unless it doesn't scale properly for larger lists.

Oh, and for other people who might be wondering, the timing values above are really "milliseconds" and not "seconds" :)

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

I noticed that none of these tests scaled very well. When I did 10k items, the time it took was absolutely huge. Though, I don't know anyone who's going to do anything like this on a 10k long list. But yeah, milliseconds, not seconds.

Also, did you see my previous post about %additem?

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

Ok. I have got questions:
1)
This works fine:

Posted: Fri Jun 18, 2010 6:57 pm

Yep, I saw the %additem issue. Creating keys that don't exist yet is on my to-do list. I want to fix it in a general way that will allow subkeys so that stuff like list.key1.key2 will also work. Not sure if I'll get this into 3.20 or not.

On #delitem, yep, I confirmed the scaling issue. I re-ran my original #additem benchmarks to confirm that they still worked, and they are even faster than before (the nosave optimization helps here). But #delitem is definitely too slow and I'm not exactly sure why. But I'm going to look into it.

Edited: Also, if I test the speed of %additem vs #ADDITEM, the %additem seems to have the same problems as #DELITEM. So maybe they are related and somewhere it's converting the list to a string when it shouldn't.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Yodous, Zugg is aware of this bug and I presume it is likely to be fixed by a release later today. http://forums.zuggsoft.com/forums/viewtopic.php?t=35331

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

Oh, right. So another thing came out with my second question. Thx for answer :)
And maybe you can give me some hint how to download the previous beta version?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Fri Jun 18, 2010 8:42 pm

As I stated in the thread where you asked this question, Youdus, the purpose of the Beta version is not to use the most stable one. It's for testing purposes, not for playability purposes. If you want a newer, stable public version, then we need to get people to test the Betas and provide exact procedures on how to recreate bugs. That's really the only way Zugg has of knowing what needs to be fixed since players around create different scripts for different things and can break things others can't.

Charneus

Posted: Fri Jun 18, 2010 8:43 pm

Please NEVER go back to a previous beta version. You can go back to the Public version, but not a previous Beta version. Going back to a previous beta version can cause your settings to be corrupted or lost. There is no compatibility going backwards.

If you are not willing to wait for the next update, then you should not be using beta versions at all.

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

Ok. Thx!

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

For v3.20

Should there be any functional difference between %db( var, "key") and %ismember( "item", var) versus %db( @var, "key") and %ismember( "item", @var)? It seems to me that they should behave exactly the same since none of them actually modify the variables passed to them. That said, it seems using the @var syntax causes a ridiculous decrease in speed as illustrated by the following script:

code:

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

Ok. And what about my seconds question:

Posted: Sat Jun 19, 2010 7:54 pm

Unless you're planning on having duplicate items in the string, then you don't need to use %additem anyway.

Charneus

Apprentice Joined: 23 Jun 2004 Posts: 105 Location: Poland

I want to do exacly what I wrote. Because I have to use hmm.. maybe another example

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

That's a bug and doesn't really have anything to due with accessing by reference versus by value, you should make a new thread.

Posted: Mon Jun 21, 2010 4:30 pm

This thread is starting to get a bit off track.

Remember to create a NEW POST is you want to report a bug.

General: I think the answer to "should these work the same..." above is "Yes", however any time you have @varname in a function, CMUD is probably going to expand it to a string value, thus slowing down the script. Without the @ a reference to the variable just gets pushed onto the internal stack rather than the string value itself.

But as the other benchmarks have already shown in other posts, there is still something wrong with the %functions in terms of their speed and scaling, so I'm already planning to look into that in more detail.