It is well known thing in C++ that calling a "new" for creating a new classes costs. Especially "framework" classes (i.e. root.cern.ch) with virtual table and probably reloaded new operator (but still based on malloc heap allocation) gains approximately the same performance on creation as was shown for VALA in this thread.
So if you need to have "empty" objects fast (for example in loops) you should better not to create but clear and reuse. If you really need to populate your memory with 100,000 objects, you'd better to have as few as possible memory allocation times. Have somebody tried creating this objects not one by one but in arrays? But in normal programming the overhead of creating the new objects vs. reusing old ones usually is less than 4%. For the .NET C# (should be same for Mono) "new" operation is not based on malloc heap allocation, but is based on allocation from some buffer called managed heap. So the "new" operation is really fast for .NET C#. If you will use .Clear() method of your class while C# users call "new" you will beat C#. Good article about memory allocation http://msdn.microsoft.com/en-us/magazine/bb985010.aspx (part 1) http://msdn.microsoft.com/en-us/magazine/bb985011.aspx (part 2) article on how much things costs http://msdn.microsoft.com/en-us/library/ms973852.aspx Some article on garbage collector performance http://msdn.microsoft.com/en-us/library/ms973837.aspx This "managed heap" is preallocated, but in case of malloc you always get the amount of memory you need. Thus you can see "but more memory efficient". It is not really efficiency for long term software living because managed heap may grow or shrink depending on memory usage. In real project one can gain efficiency in this only if one will pay much much attention to this. 2011/1/19 pancake <panc...@youterm.com> > On 01/18/11 01:54, "Andrés G. Aragoneses" wrote: > >> On 17/01/11 14:08, Jiří Zárevúcky wrote: >> >>> On Mon, Jan 17, 2011 at 1:24 AM, Didip Kerabat<did...@gmail.com> wrote: >>> >>> I don't know about any recent benchmarks, but I think Vala will >>> generally be a bit slower than Mono, but more memory efficient. >>> >> >> Slower, really? >> >> Would that be true as well for the dova profile? >> > i think (not demonstrated) that vala is faster than mono on normal > situations where you > don't build over nine thousand objects per second. > _______________________________________________ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list >
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list