Speaking a bit about performance

[Roberto Schneiders]

I'm studying this framework. I am interested in dependency injection.

A dependency injection framework is very much needed in object-oriented designs.

At first the framework seems fantastic. But I have some doubts.

Unfortunately the project is still in Beta. Do you consider that I can use it in a real project?

The framework is threadsafe?

When we use a framework for dependency injection, of course, expected a loss of performance. The question is how much performance you can sacrifice for this feature.

I did some tests to get a sense of how the framework would impact on performance.

I compared the projects "StartingOut.dproj" and "FieldInjection.dproj". In a synthetic test, performed thousands of times the method DoOrderProcessing (without writeln) and compared the execution times. The difference seemed too large, in the thousands of times.

Executions = 1000:

StartingOut: 0 milliseconds

FieldInjection: 4730 milliseconds

Executions = 10000:

StartingOut: 2 milliseconds

FieldInjection: 455515 milliseconds

In normal situations instantiate an object can not be a big problem. But in the case of a server, which I instantiate objects for each request, it can make a difference. I suppose the difference could be even greater when there dozens of classes injected.

I did a profiling using SamplingProfiling and saw that most of the processing is in the RTTI and manipulation of arrays. Results attached.

Anyone have any idea of ​​how to optimize the framework?

[Glienke, Stefan]

I think your tests have a flaw as they are including the Container.Build for every iteration.

 

If you are doing the tests with the FieldInjections Demo you need to extract the GlobalContainer.Build call from the DoOrderProcessing routine if you are calling that one in a loop.

 

100.000 calls take approx 3 seconds then here.

 

That is a huge difference to your numbers.

 

But I am not saying there is no room to improve performance. You are welcome to examine further.

--
You received this message because you are subscribed to the Google Groups "Spring Framework for Delphi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spring4d+u...@googlegroups.com.
To post to this group, send email to spri...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/spring4d/-/sZz_LO7GNYoJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Glienke, Stefan]

“The framework is threadsafe?”

 

No and that is (from a first look) at least because the TDependencyResolver uses a list to detect circular references which does not work in multithreading.

 

Von: spri...@googlegroups.com [mailto:spri...@googlegroups.com] Im Auftrag von Roberto Schneiders
Gesendet: Donnerstag, 9. Mai 2013 14:33
An: spri...@googlegroups.com
Betreff: [spring4d] Speaking a bit about performance

 

I'm studying this framework. I am interested in dependency injection.

--

[Roberto Schneiders]

You are absolutely right. My mistake.

Fix that and redid the tests:

Executions: 1000

StartingOut: 0 ms

FieldInjectoin: 25 ms

Executions: 10000

StartingOut: 2 ms

FieldInjectoin: 242 ms

Executions: 100000

StartingOut: 30 ms

FieldInjectoin: 2471 ms

The difference is much smaller and seems acceptable now. Anyway, optimizations are always welcome. If I find something I notice you.

2013/5/10 Glienke, Stefan <SGli...@aagon.com>

--
You received this message because you are subscribed to a topic in the Google Groups "Spring Framework for Delphi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spring4d/kByR7gyPMkk/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to spring4d+u...@googlegroups.com.

To post to this group, send email to spri...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Att.
Roberto Schneiders

[Glienke, Stefan]

Also keep in mind that in this example all components are registered as transient.

You will notice a huge performance increase when you change that to a singleton or pooled (pooled seems to be a bit broken currently, will investigate) registration for one or more components which might be the case in a server.

[Roberto Schneiders]

Interesting. I did not know that the framework had that option. I did find the option AsSingletonPerThread, simply fantastic.

But I'm worried about the use of multithreading. I'm using mORMot on the server and everything is multi-threaded. I'll do some tests.

Do you think it is safe to use this framework currently in production?

Regarding the thread safe, there is some planning to work on it?

thanks

2013/5/10 Glienke, Stefan <SGli...@aagon.com>

--
Att.
Roberto Schneiders

[Glienke, Stefan]

Resolving will definitely fail in a multithreading environment at the moment because the TDependencyResolver instance

which is part of the container adds and removes types during the process of resolving to prevent circular references and is not guarded by a CS.

 

I don’t know if a CS or different dependency resolver per thread is the better solution here.

 

Also I am not sure if TSingletonPerThreadLifetimeManager currently leaks memory as it does not remove the instance once the thread ends.

 

You see I am no expert in multithreading ;)

[Glienke, Stefan]

I just committed a fix for multithreading and using AsPooled.

 

Using the FieldInjection project:

 

Executions (per thread): 100000

Threads: 4

Registration: AsPooled(4, 4);

Duration: ~2000ms

[Roberto Schneiders]

Excellent.

Do you know more problems in multi-thread? or we can say that the framework is thread safe now?

2013/5/13 Glienke, Stefan <SGli...@aagon.com>

--
Att.
Roberto Schneiders

[Glienke, Stefan]

As far as I can tell the resolving part it is thread safe.