Wie heißt der Nachfolger ...

Das ist ja wirklich schade, das man nicht selbst Hand anlegen darf.
Na ja, aber dann nehm ich doch lieber C anstatt D.

Gerard

11 sekunden

#include <iostream>
#include <stdlib.h>
#include <ctime>
#include <deque>

std::deque<int> pool;

class TestClass
{
   private :
   int number;

   public :

   TestClass (int i)
   : number (i)
   {
   }

   int getNumber ()
   {
      return number;
   }

   void setNumber (int i)
   {
      number = i;
   }

   void * operator new (size_t)
   {
       pool.push_back(0);
       return &pool.back();
   }

   void operator delete(void * s)
   {
       if(&pool.front() == s) // ohne das brauche es 19 sek
           pool.pop_front();
       else
           for(std::deque<int>::iterator i = pool.begin(); i != pool.end(); ++i)
                   // kann man bestimt noch schneller lösen
           {
               if(&(*i) == s)
               {
                   pool.erase( i );
                   break;
               }
           }
   }
};

int main(int argc, char *argv[])
{
  int size = 500;
  long  sum = 0;
  clock_t time;

  TestClass ** array = new TestClass* [size];
  int i,j;

  time = clock();
  for (j = 0 ; j < 200000 ; ++j)
  {
    for (i = 0 ; i < size ; ++i)
    {
      array[i] = new TestClass(i);
    }
    for (int i = 0 ; i < size ; ++i)
    {
      sum += array[i]->getNumber ();
      delete array[i];
    }
  }
  delete [] array;
  std::cout << clock() - time;

  system("PAUSE");   
  return 0;
}

der Allocator aus Loki brachte nichts

for(std::deque<int>::iterator i = pool.begin(); i != pool.end(); ++i)

Meinst du mit "kann man sicherlich noch schneller machen" den schleifenkopf? wenn ja, wie soll man das noch schneller machen können?

Gregor

Übrigens : Mein Profiler hat mir eben verraten, dass beim Java-Programm etwa 10% der Zeit für den GC benötigt wird. Das Löschen der Objekte scheint also tatsächlich deutlich schneller zu gehen als das Erzeugen der Objekte.

EDIT : @ Dimah : Ist der Rechner vergleichbar zu Volkards und meinem?

[ Dieser Beitrag wurde am 27.11.2002 um 02:36 Uhr von Gregor editiert. ]

Was habt ihr beiden den für Rechner? (Prozessor, Speicher)

Gregor

Volkard : 400 MHz Celeron
Gregor : 1,2 GHz P4M
...beide hierbei mehr oder weniger gleich schnell.

[ Dieser Beitrag wurde am 27.11.2002 um 02:49 Uhr von Gregor editiert. ]

Hatte gerade mal Dimah's Code ausprobiert. Erst hab ich es im Debug-Modus getestet und mich gewundert, warum es garnicht fertig wurde. Das ist ja ein riesen Unterschied zwischen Release und Debug:

Release: 4426
Debug: 164837

Gregor

Bei mir braucht Dimahs Code 5878ms.

[ Dieser Beitrag wurde am 27.11.2002 um 06:59 Uhr von Gregor editiert. ]

Gerard

Original erstellt von <codezitat>:
Meinst du mit "kann man sicherlich noch schneller machen" den schleifenkopf? wenn ja, wie soll man das noch schneller machen können?

ich meine das ding algemein, z.b. duch binäre suche oder so

Original erstellt von Gregor:
**EDIT : @ Dimah : Ist der Rechner vergleichbar zu Volkards und meinem?
**

700 Mhz AMD und 312 MB 133 Mhz RAM (wobei ich glaube ich lasse die auf 100 laufen), aber ich hatte gestern noch edonkey an

vielleicht sollte ich noch was zum code sagen, er ist mist, nicht thread sicher, zugeschnitten nur auf diesen einen test.
Ich denke mit ein guten Allocator läst sich da noch was raushollen, aber auf der andern seite müsste er etwas algemeiner werden und würde da durch wieder speed verlieren

volkard

Original erstellt von Gregor:
Es wundert mich, dass folgender Hauptnachteil eines GC noch nicht genannt wurde:
Wenn man einen GC hat, dann ist das Programm in dre Regel nicht echtzeitfähig, da der GC letztendlich jederzeit aktiv werden kann und so eine große Pause produzieren kann.

Windows kann meiner Anwendung auch jederzeit mal ein halbes Sekündchen Pause schenken. Echte Echtzeit gibts ja zum Teil nicht mehr, stattdessen "Quasi-Echtzeit", daß man bei ner Aufgabe, die sekündliche Antworten braucht ein System hinstellt, das die Anfragen "normalerweise" in 1ms beantworten kann, zwar nicht nachweilslich immer schnell genug antwortet, aber sicher genug schnell genug ist, daß man seinen Kopf dafür hinhalten kann.