Re: [pygccxml-development] Another performance tweak
Brought to you by:
mbaas,
roman_yakovenko
From: Allen B. <al...@vr...> - 2006-08-27 21:22:53
|
>>>Right now I am not quite ready to update to your changes. I have some >>>concerns about the complexity and performance of the way you implemented >>>this. >>> >>> >>Do you have the numbers? I did not read the benchmark results. I will >>do this later. >> >> > >I don't have numbers. I didn't want to update and deal with the >conflicts only to find I didn't want the update. With the changes you >have made now I think it will probably be safe for me to update. I will >let you know if something goes bad. > > I now have preliminary numbers. My build that used to take 58 seconds now takes 76 seconds with your caching changes. So it looks right now like the implementations I was using were about 25% faster for some reason. Any thoughts? -Allen > > >>You are right, I introduced one more "get attribute". I have 1 good >>reason >>for this maintainability. I'd like to keep all "cached" values in >>single place. >>Thus, I don't have to scan sources for "what I am caching" and more over >>it is very easy to create documentation to it. I am sure you will not >>see this >>"get attribute" in the benchmark >> >> >> >> >>>- Why is there an "algorithms_cache_t" object as the base class to >>>"declaration_algs_cache_t"? The split with a base class doesn't seem to >>>serve much of a purpose. >>> >>> >>Enable\disable functionality. But I think it is useless now. The >>better idea is to >>introduce type_algs_cache_t class with class variable , that will >>control all >>instances of type_algs_cache_t. >> >> >> >>>- What is the performance implication of using "properties"? I know you >>>like to use them in your code but how do they affect performance? >>> >>> >>I tried with and without them and I did not see the difference. May be >>you will >>see. If you do see the difference, we can leave set_* methods and remove >>property >> >> >> >>>- Handling of enabled flag. I think the handling of the enabled flag >>>should be done in the "set" method instead of the get method. As it >>>stands with your change, our optimized path will require two if tests >>>(one in the local method to test for None, and one in the get method to >>>test enabled). If we moved the enabled test to the set method we would >>>only pay the cost of that if when we have optimizations diabled. >>> >>> >>You are right. Fixed. >> >> >> >>>>I left some interesting problem to you: it is possible to optimize >>>>declaration_path >>>>algorithm even more. In most cases its complexity could be O(1). This >>>>could be done >>>>by saving intermediate results. Another way to say it: to re-use >>>>parent declaration path >>>>cache. >>>> >>>> >>What about this? >> >> > >I haven't looked at this at all. I am not sure I understand what is >going on here well enough to do it right and it isn't showing up high in >any of my traces anymore. So it really isn't a high priority for me. > >-Allen > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >pygccxml-development mailing list >pyg...@li... >https://lists.sourceforge.net/lists/listinfo/pygccxml-development > > > |