View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000156LDMudRuntimepublic2004-11-26 20:392009-10-02 04:53
ReporterlarsAssigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Summary0000156: Performance of object memory management
DescriptionAllerdings gibt es eine kleine Ausnahme: Sowohl bei Amylaar als auch
bei MUDOS scheint das Objekt-Memory Management eine Schwachstelle zu
sein. Bei raschem Touching von sehr vielen Objekten hintereinander
kommt es zu einem dramatischen, nichlinearen(!) Anstieg der Rechenzeit.
Dass man schon mit einem relativ harmlosen Wegescipt richtig uebel Lag
produzieren kann, wenn man damit in eine ungeladene Gegend rennt,
ist wegen der Plattenzugriffe klar.
 Aber selbst bei bereits geladenen Objekten nimmt die Effektive CPUzeit
nach etwa 400 Objekten radikal nichtlinear zu. (Das Phaenomen tauchte
im Zusammenhang mit rekursiv arbeitenden Wegfinde- oder Maptools auf.
Getestet hatte ich es vor laengerem unter DOS mit einem 486er, trat aber
gleichermassen unter UNIX auf.)
Vielleicht hat ja mal jemand Lust, auf einem aktuellen System eine
Messreihe aufzunehmen?
TagsNo tags attached.
External Data (URL)

Activities

zesstra

2009-10-02 04:53

administrator   ~0001398

Maybe related, maybe not, I had on our current system the following experience:

inherit "/std/thing";
#include <properties.h>
int _query_disable_attack() {return 0;}
void create() {
  ::create();
  Set(P_DISABLE_ATTACK, #'_query_disable_attack, F_QUERY_METHOD);
}
void test() {
  foreach(int i: 10000) {
    this_object()->QueryProp(P_DISABLE_ATTACK);
  }
}
So test() would query the property 10000 and each time the function _query_disable_attack() is evaluated.

test() typically needs:
Eval-Ticks: 570327
Evaluation time: 92 ms.

but surprisingly sometimes:
Eval-Ticks: 570327
Evaluation time: 22490 ms.

Also suprising:
mixed test1() {
  int c=get_eval_cost();
  mixed arr=allocate(100,0);
  foreach(int i: 30000) {
    arr = ({i}) + arr[0..<2];
  }
  return c-get_eval_cost();
}
xcall test->test1()
Evaluation time: 61663 ms.
Result: 300017
Evaluation time: 61748 ms.
Result: 300017
Evaluation time: 224 ms.
Result: 300017
Evaluation time: 1504 ms.
Result: 300017
Evaluation time: 424 ms.
Result: 300017
Evaluation time: 11152 ms.
Result: 300017

So the second test may stop the whole mud for more than a minute, thats more a 250 fold increase in execution time. I could not trace the issue, because I can't reproduce this at home and I can't produce minute long lags the whole time. ;-)
It seems to depend on the hardware, maybe CPU cache issues?

Issue History

Date Modified Username Field Change
2004-11-26 20:39 lars New Issue
2009-10-02 04:53 zesstra Note Added: 0001398