ID:122843
 
Not a bug
BYOND Version:493
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 16.0.912.75
Applies to:DM Language
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
The verb LoadWorld_fast() will execute 6 - 7 times faster the first time it is executed. Every time after the initial execution takes 6 - 7 times longer to execute (at least in my example).
Numbered Steps to Reproduce Problem:
1. Create a New DM project
2. Create an icon
3. add 7 different icon states ("black", "green", "blue", "red", "orange", "yellow", "pink")
4. add a map, set size to 256x256x1
5. compile with the code and run world
6. click fillrand()
7. click SaveWorld_fast()
8. wait for "Complete!" message
9. close dream seeker
10. run world again
11. click LoadWorld_fast() and note execution time (~7)
12. click clearworld()
13. click LoadWorld_fast() and note execution time
(~47)

Code Snippet (if applicable) to Reproduce Problem:
world
fps = 30
icon_size = 32
view = 8
turf=/turf/black
proc
gettype(n)
switch(n)
if(1)
return /turf/red
if(2)
return /turf/blue
if(3)
return /turf/green
if(4)
return /turf/orange
if(5)
return /turf/pink
if(6)
return /turf/yellow
mob/verb
read_fast()
var/savefile/f = new("world_fast.sav")
var/ff = file("test.txt")
f.ExportText("/", ff)
fillrand()
for(var/x = 1, x < 256, x ++)
for(var/y = 1, y < 256, y++)
var/n = rand(1,6)
var/typet = gettype(n)
new typet(locate(x,y,1))
clearworld()
for(var/turf/t in world)
del(t)

SaveWorld_Fast()
var/savefile/f = new("world_fast.sav")
var/list/l = new
for(var/turf/t in world)
if(!istype(t,/turf/black))
l += "t=[t.type];x=[t.x];y=[t.y];z=[t.z]"
f << l
world << "Complete!"

LoadWorld_Fast()
var/timestart = world.timeofday
if(!fexists("world_fast.sav")) return
var/savefile/f = new("world_fast.sav")
var/list/l = new
f >> l
for(var/t in l)
var/list/params = params2list(t)
var/path = text2path(params["t"])
var/xx = text2num(params["x"])
var/yy = text2num(params["y"])
var/zz = text2num(params["z"])
new path(locate(xx,yy,zz))
world << world.timeofday - timestart

SaveWorld_Slow()
set background = 1
var/savefile/f = new("world_slow.sav")
var/list/l = new
for(var/turf/t in world)
if(!istype(t,/turf/black))
l += t
f << l

LoadWorld_Slow()
set background = 1
var/savefile/f = new("world_slow.sav")
var/list/l = new
f >> l
for(var/turf/t in l)
new t.type(locate(t.x,t.y,t.z))


turf
icon = 'turf.dmi'
Write(savefile/f)
set background = 1
f["x"] << src.x
f["y"] << src.y
f["z"] << src.z
f["icon_state"] << src.icon_state

Read(savefile/f)
set background = 1
var {tx;ty;tz};
f["x"] >> tx
f["y"] >> ty
f["z"] >> tz
f["icon_state"] >> src.icon_state


black
icon_state = "black"
red
icon_state = "red"
blue
icon_state = "blue"
green
icon_state = "green"
orange
icon_state = "orange"
pink
icon_state = "pink"
yellow
icon_state = "yellow"

atom/Click()
if(locate(src.loc) in world.contents)
if(ismob(usr))
world << "yep"
var/path=gettype(rand(1,6))
new path(src)


Expected Results:
I would expect this block of code to take roughly the same amount of execution time every time it is ran, considering the size of the world_fast.sav file does not change in size.
Actual Results:
Every execution after the initial execution of this block of code takes 6 to 7 times longer to execute.

Does the problem occur:
Every time? Or how often?
This problem occurs every time.
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:

I noticed you're calling del(turf) in clearworld(), which is wrong; you can't delete turfs except by lowering the world.maxx/y/z vars.
Should I just set it to null?
Lummox JR wrote:
I noticed you're calling del(turf) in clearworld(), which is wrong; you can't delete turfs except by lowering the world.maxx/y/z vars.

Calling del on a turf might not delete it, but it does have some effect. It appears to replace it with an instance of /turf.
Regardless, this code still runs at weird speeds, even if clear world isn't being used at all. Just login and hit load world. Wait a while... hit load world again. Slower the second time.
You can split it into multiple procs and profile it to see how much time each proc takes. That'll give you some idea of which proc is taking longer the second time you use the load verb.
Are you on the map during the second load but not the first? Your presence on the map could be triggering map updates.

I also noticed your save routine doesn't ever eliminate old saved data; you're appending to it. That could be relevant if you do more than one save. That doesn't come up in your numbered steps, so I'm taking it as more of a sign of some design issues rather than part of the bug directly.
Well the map size is always the same, and there's always 256x256 turfs to save if you do the fillrand() step (it doesn't place black turfs).

Client's mob is on the map the entire test... before loading, during loading, after loading (both times), before saving, during saving, and after saving.
If you store the data loaded from the file in a global variable and don't open the file the second time you call LoadWorld_Fast, it runs fine. This means it's not the turf creation part that's slow, it's something about opening the file a second time that's slowing things down.
Thanks for figuring that out.
Lummox JR resolved issue (Not a bug)