http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660"In most big apps, you don't. They change, they are flexible." You mean they change after compilation and they should be in some configuration file ?? http://ayende.com/4202/optimizing-windsor#comment18http://ayende.com/4202/optimizing-windsor#comment18Mon, 28 Sep 2009 09:10:10 GMTSeeR, I find code like that REALLY ugly. And you make invalid assumption when you say that you know what the dependencies are. In most big apps, you don't. They change, they are flexible. http://ayende.com/4202/optimizing-windsor#comment17http://ayende.com/4202/optimizing-windsor#comment17Sat, 26 Sep 2009 20:44:42 GMTThats the thing I can't uderstand. Why should I register all my dependencies every time my application starts if all of them are known to me (as a developer) before compilation. Here you can see how I used generics as static IoC. [seermindflow.blogspot.com/.../...y-dependency.html](http://seermindflow.blogspot.com/2009/07/c-generics-free-but-ugly-dependency.html)http://ayende.com/4202/optimizing-windsor#comment16http://ayende.com/4202/optimizing-windsor#comment16Sat, 26 Sep 2009 20:33:14 GMTScott, do you experience any concrete issue? If so, please let us know. I didn't write specific tests for this yet, but since Spring.NET's wiring logic is quite different from Windsor's, I am not sure how much of the optimizations Oren did are applicable http://ayende.com/4202/optimizing-windsor#comment15http://ayende.com/4202/optimizing-windsor#comment15Tue, 22 Sep 2009 10:17:21 GMTAyende, That's entirely correct, if you're shoe-horning this onto an existing application using Castle Windsor. It's also true if you're registering all 500 components in one method. If you distribute the registration according to the structure of your application, it's tolerable, but a waste of time. http://ayende.com/4202/optimizing-windsor#comment14http://ayende.com/4202/optimizing-windsor#comment14Fri, 18 Sep 2009 19:29:16 GMTScott, I don't know. The optimization is divided into two pieces. First, change the way we handle resolving missing dependencies to avoid the requirement for a O(N^2) per registration Second, aggressively cache resolution queries http://ayende.com/4202/optimizing-windsor#comment13http://ayende.com/4202/optimizing-windsor#comment13Fri, 18 Sep 2009 14:50:48 GMTjust curious if similar optimizations could be made in Spring.Net's IoC, or if the same logic would apply http://ayende.com/4202/optimizing-windsor#comment12http://ayende.com/4202/optimizing-windsor#comment12Fri, 18 Sep 2009 14:46:58 GMTChris, That is usually not possible. If I have 500 components, just trying to figure out what the right order is is longer than the registration time. http://ayende.com/4202/optimizing-windsor#comment11http://ayende.com/4202/optimizing-windsor#comment11Fri, 18 Sep 2009 14:23:17 GMTEven so, it's better to register your components in an order that ensures the fewest number of components is awaiting dependencies at a time. CAB might have been onto something there :) http://ayende.com/4202/optimizing-windsor#comment10http://ayende.com/4202/optimizing-windsor#comment10Fri, 18 Sep 2009 12:40:50 GMTAyende, Ah, I see. This discussion seems to be degenerating into mathematics ;-) AFAIK with big O notation you're interested in how the algorithm varies with N. So constants, e.g. division by 2, don't vary and are thus dropped from the notation. 1,2,3...N is the canonical arithmetic sequence, the sum of which is given by N(N+1)/2. Since you're starting at zero, i.e. =N-1, the sum becomes N(N-1)/2. OK, "normal programming service has been resumed..." ;-) http://ayende.com/4202/optimizing-windsor#comment9http://ayende.com/4202/optimizing-windsor#comment9Fri, 18 Sep 2009 11:26:57 GMTDarius, I suppose not that many people usually have that many distinct components served up by the DI container. that's the problem with exponential performance loss... http://ayende.com/4202/optimizing-windsor#comment8http://ayende.com/4202/optimizing-windsor#comment8Fri, 18 Sep 2009 11:19:50 GMTMike, Yes & no. a) you need to pay attention to what N represent (invalid components) b) it isn't the same N. Let us say we add 100 invalid components. 1st: O(0) 2nd: O(1) 3rd: O(2) 100: O(99) I am not sure what the math symbol for that is. It is usually close enough to O(N^2 / 2) * N, though. I changed it so it would be O(N^2) without the Optimize and O(N) with the Optimize http://ayende.com/4202/optimizing-windsor#comment7http://ayende.com/4202/optimizing-windsor#comment7Fri, 18 Sep 2009 10:36:03 GMTTo clarify, you're saying that the original algorithm was an O(N^2) operation for each of N components and you initially got this down to O(N)? So in fact the registration of all components was N * O(N^2) = O(N^3) and you got it down to O(N^2)? No wonder it was taking so long for large numbers ;-) http://ayende.com/4202/optimizing-windsor#comment6http://ayende.com/4202/optimizing-windsor#comment6Fri, 18 Sep 2009 10:29:55 GMTStrange nobody else stumbled upon this. And great that it is now improved! Thanks both for those who reported the bug, and who fixed it! http://ayende.com/4202/optimizing-windsor#comment5http://ayende.com/4202/optimizing-windsor#comment5Fri, 18 Sep 2009 09:53:44 GMTRicardo, Check the SVN log :-) http://ayende.com/4202/optimizing-windsor#comment4http://ayende.com/4202/optimizing-windsor#comment4Fri, 18 Sep 2009 09:49:00 GMTJust for curiosity, could you share with us the details of the optimization? http://ayende.com/4202/optimizing-windsor#comment3http://ayende.com/4202/optimizing-windsor#comment3Fri, 18 Sep 2009 09:44:35 GMTDennis, After they had some chance to sit in the trunk and we can see that they are stable. http://ayende.com/4202/optimizing-windsor#comment2http://ayende.com/4202/optimizing-windsor#comment2Fri, 18 Sep 2009 09:42:50 GMTWhen can we expect a release with this? (We dont like running with the SVN version) http://ayende.com/4202/optimizing-windsor#comment1http://ayende.com/4202/optimizing-windsor#comment1Fri, 18 Sep 2009 08:15:11 GMT