loadWindowLayout is slow

[zanir]

I use dynamic loading of new layouts but it is slow. Loading of layout with 38 controls last 0.2 second on relase build (1.2 second on debug). I did performance profiling and I found out that CEGUI is creting about 300 windows and for each window sets about 40 properties. So addProperty(Property* property) is called 12114 times.

Is there some possibility to speed up loading of layouts? Are all 40 properties necessary to add for each window?

I have one suggestion to speed up addProperty function:

old code:

Code: Select all

void PropertySet::addProperty(Property* property)
{
   if (!property)
   {
      throw NullObjectException("The given Property object pointer is invalid.");
   }

   if (d_properties.find(property->getName()) != d_properties.end())
   {
      throw AlreadyExistsException("A Property named '" + property->getName() + "' already exists in the PropertySet.");
   }

   d_properties[property->getName()] = property;
}


new code:

Code: Select all

void PropertySet::addProperty(Property* property)
{
   if (!property)
   {
      throw NullObjectException("The given Property object pointer is invalid.");
   }

   if (!d_properties.insert(PropertyRegistry::value_type(property->getName(),property)).second)
   {
      throw AlreadyExistsException("A Property named '" + property->getName() + "' already exists in the PropertySet.");
   }
}


Could somebody review and submit this code change?

[ppl]

operator[] is definitely a slow way to modify a map. I'd be curious to know how much speedup you gain from your change. Can you offer a second benchmark?

[zanir]

I did performance profiling on debug build. Loading of the layout last 2800 ms. Time in addProperty function was 990 ms with old code. With the new code time dropped to 650 ms. It is approximately about 1/3 faster.

The majority of time was lasted in both cases in finding a property by name in map. In the old code it happens 2 times in the new only one.

[ppl]

I also did my own little benchmark with 5 pass for each test.

With the current implementation:

Median: 27.751s

With your optimization:

Median: 17.484s

So, according to my test you would get 36% speed up which should save you 346.5 ms (you benchmarked 340ms).

I also rigged something quick with hash + your fix and I got

Median: 15.906s

Which gives you a 42% speed up. That would save you something like 415.8ms (save you an extra 75ms). My hash test wasn't very representative though.

I think it's just a matter of time before someone with a commit bit see this message and update the code in svn.

Thanks for the profiling and optimization!

Note: Oops, by hash I didn't meant an hash table. I simply replaced the key with an integer hash (Just for fun ).