PennMUSH & DBREFs
-
I'm curious, has anyone seen a PennMUSH that went into the 10s of 1,000s of DBREFs and if so did it negatively impact the game's general performance?
Pay no attention to me. I'm old, jaded and generally unfriendly. I am prone to fits of stupidity, but I am still unique, just like everyone else. ~~ Current President of the Anti-Faraday fan club.
-
Anecdotally, and entirely in hearsay, I've heard Penn's database loads and saves get pathologically slow with even a moderately large database.
I can not provide any supporting evidence for this claim but have heard it several times from reliable sources.
-
It might be easier to go to the Penn devsite and ask, there's so few of us running Penn around here. The flagship/dev game though, has almost 13000 objects(many of them coded systems like just, random coded games people play) and doesn't seem to have any slowdown that I've ever witnessed or experienced.
-
@Seamus said in PennMUSH & DBREFs:
I'm curious, has anyone seen a PennMUSH that went into the 10s of 1,000s of DBREFs and if so did it negatively impact the game's general performance?
I"ve not personally seen slowdown in execution of code, but I have seen first hand much slower save times with larger number of dbref#'s and more attributes per dbref#'s in PennMUSH.
I'm not sure why. May be related to the unique way they store their data compared to other systems.
-
@Ashen-Shugar Would this depend primarily on the type of compression they use? Or is it simply a side effect of a large database?
He/Him
-
@ixokai said in PennMUSH & DBREFs:
Anecdotally, and entirely in hearsay, I've heard Penn's database loads and saves get pathologically slow with even a moderately large database.
I can not provide any supporting evidence for this claim but have heard it several times from reliable sources.
This is true, when you hit around 40k objects.
High number of Attributes on singular objects however, cause far more slowdown than the object count. -
@Tinuviel said in PennMUSH & DBREFs:
@Ashen-Shugar Would this depend primarily on the type of compression they use? Or is it simply a side effect of a large database?
I honestly wish I could answer this, but I really don't have one.
I've not tore apart PennMUSH at that level and ran it through any sort of performance analysis.
I'd first really want to run it through something like valgrind just to see where all the allocations and deallocations were occuring.
This could be nothing more than poorly managed memory, but again, without really digging into the code and tagging it with a performance engine debugger all I can do is speculate.
