pygccxml-development Mailing List for C++ Python language bindings (Page 43)
Brought to you by:
mbaas,
roman_yakovenko
Menu
▾
▴
pygccxml-development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(6) |
Mar
(160) |
Apr
(96) |
May
(152) |
Jun
(72) |
Jul
(99) |
Aug
(189) |
Sep
(161) |
Oct
(110) |
Nov
(9) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(13) |
Feb
(48) |
Mar
(35) |
Apr
(7) |
May
(37) |
Jun
(8) |
Jul
(15) |
Aug
(8) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(38) |
| 2008 |
Jan
(11) |
Feb
(29) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(64) |
Jul
(49) |
Aug
(51) |
Sep
(18) |
Oct
(22) |
Nov
(9) |
Dec
(9) |
| 2009 |
Jan
(28) |
Feb
(15) |
Mar
(2) |
Apr
(11) |
May
(6) |
Jun
(2) |
Jul
(3) |
Aug
(34) |
Sep
(5) |
Oct
(7) |
Nov
(13) |
Dec
(14) |
| 2010 |
Jan
(39) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(11) |
Jun
(8) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|
From: Matthias B. <ba...@ir...> - 2006-08-29 07:09:56
|
Roman Yakovenko wrote:
>> ERROR: test (operators_tester.tester_t)
>
> Can you send the error?
gccxml (0.6.0) produces errors on a Boost header which look like this:
gccxml_runtime_error_t: Error occured while running GCC-XML: In file
included from
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_arithmetic.hpp:12,
from
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/arithmetic_traits.hpp:14,
from
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/detail/ob_call_traits.hpp:27,
from
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/call_traits.hpp:19,
from
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/rational.hpp:48,
from
D:/home/baas/Projekte/pyplusplus/pyplusplus_dev/unittests/data/operators_to_be_exported.hpp:9:
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_integral.hpp:47:
error: syntax
error before `>' token
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_integral.hpp:47:
error: syntax
error before `>' token
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_integral.hpp:47:
error: syntax
error before `;' token
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_integral.hpp:47:
error: `
friend' can only be specified inside a class
.
.
.
.
.
C:/Programme/Programmieren/boost/include/boost-1_33_1/boost/type_traits/is_integral.hpp:48:
internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
So it doesn't look like this is an error in Py++.
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-08-29 05:14:35
|
On 8/29/06, Allen Bierbaum <al...@vr...> wrote:
>
> As requested, I have backed out these changes. The implementation is
> now available for people to use in goodies.goodies_perf_overrides.py.
> Just import that file and you will get the full module caching as well
> as the create_identifier override.
>
I don't like the way you do it. There was good reason to remove it -
critical bug.
I did not see the code you added to goodies, but I assume it contains same
bug.
Bug description:
Lets say you have 2 header files:
implementation_details.h
...
and
to_be_exported.h:
#include "implementation_details.h"
....
Py++ code:
mb = module_builder_t( "to_be_exported.h" )
The problem with Allen implementation is that you can change
"implementation_details.h"
file, but "cache" will remain valid. In this case module_builder_t should
rebuild the cache, otherwise
Py++ will generate wrong code. This is a very critical bug. pygccxml cache
classes know
to deal with this situation.
There was another bug: module_builder_t.__init__ can take not only file
paths but also
text, that contains valid C++ code. The Allen's code does not deal with them
at all.
I proposed to Allen to create and implement module_builder_t cache class
in terms of pygccxml classes.
I am pretty busy this days, so I don't have time to fix the bug. Thus the
code has been removed.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-08-28 22:10:07
|
As requested, I have backed out these changes. The implementation is now available for people to use in goodies.goodies_perf_overrides.py. Just import that file and you will get the full module caching as well as the create_identifier override. -Allen Allen Bierbaum wrote: >Roman Yakovenko wrote: > > > >>Hi. I review the functionality you added to module builder, also I >>like the idea, >>I don't agree with implementation. >> >>1. You can not use "print" statements within the code. Please change them to >> self.logger.debug, except loading and save messages. In my opinion >> they should be info. >> >> >> >> >Agreed. those should not be there. I will fix it. > > > >>2. pygccxml class defines cache classes, why you can not reuse one of them? >> >> >> >> >I use the signature methods from there, but the cache classes from there >are based on the concept of mapping from a key to a cached value. In >this case we just want to load/dump the state of a single object that we >know ahead of time and we only want to load it if we know the key >matches. This is a different set of requirements so I just did it locally. > > > >>3. Why do you think it could be useful to have cache and module_cache >> arguments? In my opinion, if you want to provide simple interface >>leave only one >> of them - cache and make it work with pygccxml. >> >> >> >> >> >I did it this way so I didn't break the old API in any way. I have no >problem with changing it though if you support the change. > >-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 > > > |
|
From: Allen B. <al...@vr...> - 2006-08-28 20:23:17
|
Roman Yakovenko wrote: >Hi. I review the functionality you added to module builder, also I >like the idea, >I don't agree with implementation. > >1. You can not use "print" statements within the code. Please change them to > self.logger.debug, except loading and save messages. In my opinion > they should be info. > > Agreed. those should not be there. I will fix it. >2. pygccxml class defines cache classes, why you can not reuse one of them? > > I use the signature methods from there, but the cache classes from there are based on the concept of mapping from a key to a cached value. In this case we just want to load/dump the state of a single object that we know ahead of time and we only want to load it if we know the key matches. This is a different set of requirements so I just did it locally. >3. Why do you think it could be useful to have cache and module_cache > arguments? In my opinion, if you want to provide simple interface >leave only one > of them - cache and make it work with pygccxml. > > > I did it this way so I didn't break the old API in any way. I have no problem with changing it though if you support the change. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-28 20:03:04
|
Hi. I review the functionality you added to module builder, also I
like the idea,
I don't agree with implementation.
1. You can not use "print" statements within the code. Please change them to
self.logger.debug, except loading and save messages. In my opinion
they should be info.
2. pygccxml class defines cache classes, why you can not reuse one of them?
3. Why do you think it could be useful to have cache and module_cache
arguments? In my opinion, if you want to provide simple interface
leave only one
of them - cache and make it work with pygccxml.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-08-28 19:24:08
|
Allen Bierbaum wrote: > I found one other place. Using make_flatten_generator in pyplusplus > (exposing it and then using it actually) shaves off another 8-10%. > > The profile list now looks pretty flat. In other words there is > nothing dominating. All of the cached methods are now showing up as > the most costly in the profile but they are all about equal in terms > of time. I would still like to see a faster implementation of these > things so we can get back that extra 25% increase but I guess i will > live with it if you don't want to optimize it further. One correction here. remove_alias is definitely the most expensive method remaining. It currently takes up about 13% of the run-time. -Allen > > I think any remaining optimizations will need to be done by making > algorithms smarter so they do less work. For now I think I am done > with my optimization efforts though. I need to get real work done. > > -Allen > > > Allen Bierbaum wrote: > >> Roman Yakovenko wrote: >> >> >> >>> On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >>> >>> >>> >>>> Roman Yakovenko wrote: >>>> >>>> >>>> >>>>> On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >>>>> >>>>> >>>>> >>>>>> Roman Yakovenko wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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? >>>>>>>> >>>>>>> >>>>>>> I don't know why, but I think I prefer to pay this price. I prefer >>>>>>> code, that I can maintain. Sorry. >>>>>>> >>>>>> >>>>>> It is probably no surprise that I disagree. The extra 25% >>>>> >>>> performance >>>> >>>> >>>>>> seems like a good thing to me. >>>>>> >>>>> >>>>> :-). It is not 25%. The original time was 12 minutes. Your >>>>> optimization brought it to >>>>> 1 minutes, than my changes brought it to 1.25 minutes. >>>>> >>>> >>>> The 25% is that in my current version, my implementations take 58 >>>> seconds and with yours it takes 76 seconds. That is a 25% difference >>>> with my math at least. :) >>>> >>> >>> I count from 12 minutes. >>> >> >> >> Well that is just cheating then. :) >> >> >> >>>>>> Why were the extra layers of indirection needed in your >>>>> >>>> implementation? >>>> >>>> >>>>>> In my implementation I just tried to keep everything local to the >>>>>> >>>>> >>>> method >>>> >>>> >>>>>> I was optimizing. In that way I thought it was pretty maintainable >>>>>> because that method was the only place in the code that set or >>>>>> >>>>> >>>> used the >>>> >>>> >>>>>> cache value. This still allowed for disabling caching by using a >>>>>> >>>>> >>>> module >>>> >>>> >>>>>> level variable to prevent the cache from being set. >>>>>> >>>>>> What caused this local encapsulation to be less maintainable? >>>>>> >>>>> >>>>> You can not answer the question "what optimization pygccxml does" >>>>> >>>> >>>> without >>>> >>>> >>>>> scanning the whole source code. pygccxml supports "file by file" >>>>> compilation mode. >>>>> When it joins the declarations tree, it have to clear all declaration >>>>> and type caches. >>>>> It is very easy to write decl.cache.reset(). While in your case, >>>>> developer ( me ) has >>>>> always scan all sources and to find out what attributes should be >>>>> reset. Another problem >>>>> is when new "cache value" is introduced. I can bet, that I will >>>>> forget >>>>> to add it to all >>>>> places where I need reset. Thus the software will become buggy. >>>>> >>>>> This is just an example to problem my implementation solves. There is >>>>> new concept >>>>> in pygccxml "cache" and I want it to be presented in a right way. >>>>> >>>> >>>> Why didn't I need the ability to reset in my versions? >>>> >>> >>> You do. You didn't run unit tests, right? Otherwise typedef_tester.py >>> would fail. >>> >> >> >> I ran the unit tests but maybe I missed it for remove_alias. >> >> >> >>>> Do all the >>>> methods really need reset. I mean why do we have to reset something >>>> that is always constant for a given decl? (ex: access type) >>>> >>> >>> You treat pygccxml declarations tree as read only, right? If you >>> think about >>> read\write than you really need to reset it. >>> >>> >>> >>>> I agree, if there are multiple places in the code where the cache >>>> would >>>> have to be reset or touched then that is an issue. But I didn't run >>>> across that with my implementations. I know you had a corner case >>>> with >>>> remove_alias that took a long time to track down, was that because of >>>> needing a reset? >>>> >>> >>> Yes. >>> removed_alias on a typedef, after join of declarations tree contained >>> reference to >>> the removed class. Some operation stopped working. After this I >>> understand, that to be >>> on a safe side I need to reset declaration cache too. >>> >>> >>> >>>>>>> You already achieved x10 improvement. This is a grate result. Lets >>>>>>> stop here. >>>>>>> >>>>>>> >>>>>> >>>>>> I don't know if I will ever stop looking for ways to make this >>>>>> >>>>> >>>> code run >>>> >>>> >>>>>> faster, but I will probably stop soon so I can just use the code >>>>>> >>>>> >>>> instead >>>> >>>> >>>>>> of trying to improve it. >>>>>> >>>>> >>>>> Please don't take it personal, without your ideas and work Py++ would >>>>> not become >>>>> such powerful and good tool. >>>>> >>>> >>>> I don't take it personal. I just really need py++ to run faster so I >>>> can work with it more easily. It is much better now then it was, but >>>> now that I have seen how many opportunities there are for >>>> improvement I >>>> just want to make sure I don't miss any easy fixes. :) >>>> >>> >>> I did not optimize Py++ at all. I just make it to run "fast enough" on >>> my projects. >>> So please do it. >>> >>> >> >> I am still trying to make it "fast enough" for my projects. :) >> >> -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 >> >> >> > |
|
From: Allen B. <al...@vr...> - 2006-08-28 19:22:59
|
I found one other place. Using make_flatten_generator in pyplusplus (exposing it and then using it actually) shaves off another 8-10%. The profile list now looks pretty flat. In other words there is nothing dominating. All of the cached methods are now showing up as the most costly in the profile but they are all about equal in terms of time. I would still like to see a faster implementation of these things so we can get back that extra 25% increase but I guess i will live with it if you don't want to optimize it further. I think any remaining optimizations will need to be done by making algorithms smarter so they do less work. For now I think I am done with my optimization efforts though. I need to get real work done. -Allen Allen Bierbaum wrote: >Roman Yakovenko wrote: > > > >>On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >> >> >> >>>Roman Yakovenko wrote: >>> >>> >>> >>>>On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >>>> >>>> >>>> >>>>>Roman Yakovenko wrote: >>>>> >>>>> >>>>> >>>>>>On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >>>>>> >>>>>> >>>>>> >>>>>>>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? >>>>>>> >>>>>>> >>>>>>I don't know why, but I think I prefer to pay this price. I prefer >>>>>>code, that I can maintain. Sorry. >>>>>> >>>>>> >>>>>It is probably no surprise that I disagree. The extra 25% >>>>> >>>>> >>>performance >>> >>> >>>>>seems like a good thing to me. >>>>> >>>>> >>>>:-). It is not 25%. The original time was 12 minutes. Your >>>>optimization brought it to >>>>1 minutes, than my changes brought it to 1.25 minutes. >>>> >>>> >>>The 25% is that in my current version, my implementations take 58 >>>seconds and with yours it takes 76 seconds. That is a 25% difference >>>with my math at least. :) >>> >>> >>I count from 12 minutes. >> >> > >Well that is just cheating then. :) > > > >>>>>Why were the extra layers of indirection needed in your >>>>> >>>>> >>>implementation? >>> >>> >>>>>In my implementation I just tried to keep everything local to the >>>>> >>>>> >>>method >>> >>> >>>>>I was optimizing. In that way I thought it was pretty maintainable >>>>>because that method was the only place in the code that set or >>>>> >>>>> >>>used the >>> >>> >>>>>cache value. This still allowed for disabling caching by using a >>>>> >>>>> >>>module >>> >>> >>>>>level variable to prevent the cache from being set. >>>>> >>>>>What caused this local encapsulation to be less maintainable? >>>>> >>>>> >>>>You can not answer the question "what optimization pygccxml does" >>>> >>>> >>>without >>> >>> >>>>scanning the whole source code. pygccxml supports "file by file" >>>>compilation mode. >>>>When it joins the declarations tree, it have to clear all declaration >>>>and type caches. >>>>It is very easy to write decl.cache.reset(). While in your case, >>>>developer ( me ) has >>>>always scan all sources and to find out what attributes should be >>>>reset. Another problem >>>>is when new "cache value" is introduced. I can bet, that I will forget >>>>to add it to all >>>>places where I need reset. Thus the software will become buggy. >>>> >>>>This is just an example to problem my implementation solves. There is >>>>new concept >>>>in pygccxml "cache" and I want it to be presented in a right way. >>>> >>>> >>>Why didn't I need the ability to reset in my versions? >>> >>> >>You do. You didn't run unit tests, right? Otherwise typedef_tester.py >>would fail. >> >> > >I ran the unit tests but maybe I missed it for remove_alias. > > > >>>Do all the >>>methods really need reset. I mean why do we have to reset something >>>that is always constant for a given decl? (ex: access type) >>> >>> >>You treat pygccxml declarations tree as read only, right? If you think >>about >>read\write than you really need to reset it. >> >> >> >>>I agree, if there are multiple places in the code where the cache would >>>have to be reset or touched then that is an issue. But I didn't run >>>across that with my implementations. I know you had a corner case with >>>remove_alias that took a long time to track down, was that because of >>>needing a reset? >>> >>> >>Yes. >>removed_alias on a typedef, after join of declarations tree contained >>reference to >>the removed class. Some operation stopped working. After this I >>understand, that to be >>on a safe side I need to reset declaration cache too. >> >> >> >>>>>>You already achieved x10 improvement. This is a grate result. Lets >>>>>>stop here. >>>>>> >>>>>> >>>>>> >>>>>I don't know if I will ever stop looking for ways to make this >>>>> >>>>> >>>code run >>> >>> >>>>>faster, but I will probably stop soon so I can just use the code >>>>> >>>>> >>>instead >>> >>> >>>>>of trying to improve it. >>>>> >>>>> >>>>Please don't take it personal, without your ideas and work Py++ would >>>>not become >>>>such powerful and good tool. >>>> >>>> >>>I don't take it personal. I just really need py++ to run faster so I >>>can work with it more easily. It is much better now then it was, but >>>now that I have seen how many opportunities there are for improvement I >>>just want to make sure I don't miss any easy fixes. :) >>> >>> >>I did not optimize Py++ at all. I just make it to run "fast enough" on >>my projects. >>So please do it. >> >> >> >I am still trying to make it "fast enough" for my projects. :) > >-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 > > > |
|
From: Roman Y. <rom...@gm...> - 2006-08-28 16:47:17
|
On 8/28/06, Matthias Baas <ba...@ir...> wrote: > > Here are a few comments on the setup: > > - I made a small change to autoconfig.py so that the paths in > environment.py can use native backslashes on Windows. Thanks > - Shouldn't the name of the Boost.Python lib also be in environment.py? > I take it this file contains all the user/platform dependent setting > whereas autoconfig.py is a fixed file. In my case, I had to change the > name in autoconfig.py. Yes, it could be there > - I think the test for gccxml.executable is too strict. The script > aborts when it cannot find a file that is specified in this variable. > This forced me to specify an absolute path which wouldn't have been > necessary because I have gccxml in my PATH. You can change it for your user. I prefer to see full paths. It is easier for me to setup new environment. > - When I run test_all.py I get 4 failures: > > [I don't see the first failure as the buffer of the DOS box is too small] > ERROR: test (operators_tester.tester_t) Can you send the error? > ERROR: test (indexing_suites2_tester.tester_t) Try to add indexing suite 2. You will find instructions in pyplusplus_dev/indexing_suite_v2 > ERROR: test (no_init_tester.tester_t) I still work on it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-28 14:55:20
|
Roman Yakovenko wrote: > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > >> Roman Yakovenko wrote: >> >> > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >> > >> >> Roman Yakovenko wrote: >> >> >> >> > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >> >> > >> >> >> 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? >> >> > >> >> > >> >> > I don't know why, but I think I prefer to pay this price. I prefer >> >> > code, that I can maintain. Sorry. >> >> >> >> It is probably no surprise that I disagree. The extra 25% >> performance >> >> seems like a good thing to me. >> > >> > >> > :-). It is not 25%. The original time was 12 minutes. Your >> > optimization brought it to >> > 1 minutes, than my changes brought it to 1.25 minutes. >> >> The 25% is that in my current version, my implementations take 58 >> seconds and with yours it takes 76 seconds. That is a 25% difference >> with my math at least. :) > > > I count from 12 minutes. Well that is just cheating then. :) > >> > >> >> Why were the extra layers of indirection needed in your >> implementation? >> >> >> >> In my implementation I just tried to keep everything local to the >> method >> >> I was optimizing. In that way I thought it was pretty maintainable >> >> because that method was the only place in the code that set or >> used the >> >> cache value. This still allowed for disabling caching by using a >> module >> >> level variable to prevent the cache from being set. >> >> >> >> What caused this local encapsulation to be less maintainable? >> > >> > >> > You can not answer the question "what optimization pygccxml does" >> without >> > scanning the whole source code. pygccxml supports "file by file" >> > compilation mode. >> > When it joins the declarations tree, it have to clear all declaration >> > and type caches. >> > It is very easy to write decl.cache.reset(). While in your case, >> > developer ( me ) has >> > always scan all sources and to find out what attributes should be >> > reset. Another problem >> > is when new "cache value" is introduced. I can bet, that I will forget >> > to add it to all >> > places where I need reset. Thus the software will become buggy. >> > >> > This is just an example to problem my implementation solves. There is >> > new concept >> > in pygccxml "cache" and I want it to be presented in a right way. >> >> Why didn't I need the ability to reset in my versions? > > > You do. You didn't run unit tests, right? Otherwise typedef_tester.py > would fail. I ran the unit tests but maybe I missed it for remove_alias. > >> Do all the >> methods really need reset. I mean why do we have to reset something >> that is always constant for a given decl? (ex: access type) > > > You treat pygccxml declarations tree as read only, right? If you think > about > read\write than you really need to reset it. > >> I agree, if there are multiple places in the code where the cache would >> have to be reset or touched then that is an issue. But I didn't run >> across that with my implementations. I know you had a corner case with >> remove_alias that took a long time to track down, was that because of >> needing a reset? > > > Yes. > removed_alias on a typedef, after join of declarations tree contained > reference to > the removed class. Some operation stopped working. After this I > understand, that to be > on a safe side I need to reset declaration cache too. > >> >> > You already achieved x10 improvement. This is a grate result. Lets >> >> > stop here. >> >> > >> >> I don't know if I will ever stop looking for ways to make this >> code run >> >> faster, but I will probably stop soon so I can just use the code >> instead >> >> of trying to improve it. >> > >> > >> > Please don't take it personal, without your ideas and work Py++ would >> > not become >> > such powerful and good tool. >> >> I don't take it personal. I just really need py++ to run faster so I >> can work with it more easily. It is much better now then it was, but >> now that I have seen how many opportunities there are for improvement I >> just want to make sure I don't miss any easy fixes. :) > > > I did not optimize Py++ at all. I just make it to run "fast enough" on > my projects. > So please do it. > I am still trying to make it "fast enough" for my projects. :) -Allen |
|
From: Matthias B. <ba...@ir...> - 2006-08-28 14:16:03
|
Roman Yakovenko wrote: >> What additional configuration is required to run the unit tests? I >> always get an error 'include path "" should exists or to be a valid >> directory name.' whenever I run a test. > > There are 3 files you should add you settings in: > pygccxml: > unittests/autoconfig.py > Py++: > pyplusplus_dev/ environment.py > pyplusplus_dev/unittests/autoconfig.py All right, I didn't notice the file environment.py. I added my paths to that file and now it seems to work. Here are a few comments on the setup: - I made a small change to autoconfig.py so that the paths in environment.py can use native backslashes on Windows. - Shouldn't the name of the Boost.Python lib also be in environment.py? I take it this file contains all the user/platform dependent setting whereas autoconfig.py is a fixed file. In my case, I had to change the name in autoconfig.py. - I think the test for gccxml.executable is too strict. The script aborts when it cannot find a file that is specified in this variable. This forced me to specify an absolute path which wouldn't have been necessary because I have gccxml in my PATH. - When I run test_all.py I get 4 failures: [I don't see the first failure as the buffer of the DOS box is too small] ERROR: test (operators_tester.tester_t) ERROR: test (indexing_suites2_tester.tester_t) ERROR: test (no_init_tester.tester_t) Is that ok? (well, I know it's not ok, but I mean, do you get those, too?) Do the tests run on Windows properly anyway? (I already had problems with gccxml on Windows before) - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-08-28 13:38:17
|
On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > Roman Yakovenko wrote: > > > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > > > >> Roman Yakovenko wrote: > >> > >> > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > >> > > >> >> 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? > >> > > >> > > >> > I don't know why, but I think I prefer to pay this price. I prefer > >> > code, that I can maintain. Sorry. > >> > >> It is probably no surprise that I disagree. The extra 25% performance > >> seems like a good thing to me. > > > > > > :-). It is not 25%. The original time was 12 minutes. Your > > optimization brought it to > > 1 minutes, than my changes brought it to 1.25 minutes. > > The 25% is that in my current version, my implementations take 58 > seconds and with yours it takes 76 seconds. That is a 25% difference > with my math at least. :) I count from 12 minutes. > > > >> Why were the extra layers of indirection needed in your implementation? > >> > >> In my implementation I just tried to keep everything local to the method > >> I was optimizing. In that way I thought it was pretty maintainable > >> because that method was the only place in the code that set or used the > >> cache value. This still allowed for disabling caching by using a module > >> level variable to prevent the cache from being set. > >> > >> What caused this local encapsulation to be less maintainable? > > > > > > You can not answer the question "what optimization pygccxml does" without > > scanning the whole source code. pygccxml supports "file by file" > > compilation mode. > > When it joins the declarations tree, it have to clear all declaration > > and type caches. > > It is very easy to write decl.cache.reset(). While in your case, > > developer ( me ) has > > always scan all sources and to find out what attributes should be > > reset. Another problem > > is when new "cache value" is introduced. I can bet, that I will forget > > to add it to all > > places where I need reset. Thus the software will become buggy. > > > > This is just an example to problem my implementation solves. There is > > new concept > > in pygccxml "cache" and I want it to be presented in a right way. > > Why didn't I need the ability to reset in my versions? You do. You didn't run unit tests, right? Otherwise typedef_tester.py would fail. > Do all the > methods really need reset. I mean why do we have to reset something > that is always constant for a given decl? (ex: access type) You treat pygccxml declarations tree as read only, right? If you think about read\write than you really need to reset it. > I agree, if there are multiple places in the code where the cache would > have to be reset or touched then that is an issue. But I didn't run > across that with my implementations. I know you had a corner case with > remove_alias that took a long time to track down, was that because of > needing a reset? Yes. removed_alias on a typedef, after join of declarations tree contained reference to the removed class. Some operation stopped working. After this I understand, that to be on a safe side I need to reset declaration cache too. > >> > You already achieved x10 improvement. This is a grate result. Lets > >> > stop here. > >> > > >> I don't know if I will ever stop looking for ways to make this code run > >> faster, but I will probably stop soon so I can just use the code instead > >> of trying to improve it. > > > > > > Please don't take it personal, without your ideas and work Py++ would > > not become > > such powerful and good tool. > > I don't take it personal. I just really need py++ to run faster so I > can work with it more easily. It is much better now then it was, but > now that I have seen how many opportunities there are for improvement I > just want to make sure I don't miss any easy fixes. :) I did not optimize Py++ at all. I just make it to run "fast enough" on my projects. So please do it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Allen B. <al...@vr...> - 2006-08-28 13:29:19
|
Roman Yakovenko wrote: > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > >> Roman Yakovenko wrote: >> >> > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: >> > >> >> 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? >> > >> > >> > I don't know why, but I think I prefer to pay this price. I prefer >> > code, that I can maintain. Sorry. >> >> It is probably no surprise that I disagree. The extra 25% performance >> seems like a good thing to me. > > > :-). It is not 25%. The original time was 12 minutes. Your > optimization brought it to > 1 minutes, than my changes brought it to 1.25 minutes. The 25% is that in my current version, my implementations take 58 seconds and with yours it takes 76 seconds. That is a 25% difference with my math at least. :) > >> Why were the extra layers of indirection needed in your implementation? >> >> In my implementation I just tried to keep everything local to the method >> I was optimizing. In that way I thought it was pretty maintainable >> because that method was the only place in the code that set or used the >> cache value. This still allowed for disabling caching by using a module >> level variable to prevent the cache from being set. >> >> What caused this local encapsulation to be less maintainable? > > > You can not answer the question "what optimization pygccxml does" without > scanning the whole source code. pygccxml supports "file by file" > compilation mode. > When it joins the declarations tree, it have to clear all declaration > and type caches. > It is very easy to write decl.cache.reset(). While in your case, > developer ( me ) has > always scan all sources and to find out what attributes should be > reset. Another problem > is when new "cache value" is introduced. I can bet, that I will forget > to add it to all > places where I need reset. Thus the software will become buggy. > > This is just an example to problem my implementation solves. There is > new concept > in pygccxml "cache" and I want it to be presented in a right way. Why didn't I need the ability to reset in my versions? Do all the methods really need reset. I mean why do we have to reset something that is always constant for a given decl? (ex: access type) I agree, if there are multiple places in the code where the cache would have to be reset or touched then that is an issue. But I didn't run across that with my implementations. I know you had a corner case with remove_alias that took a long time to track down, was that because of needing a reset? >> > You already achieved x10 improvement. This is a grate result. Lets >> > stop here. >> > >> I don't know if I will ever stop looking for ways to make this code run >> faster, but I will probably stop soon so I can just use the code instead >> of trying to improve it. > > > Please don't take it personal, without your ideas and work Py++ would > not become > such powerful and good tool. I don't take it personal. I just really need py++ to run faster so I can work with it more easily. It is much better now then it was, but now that I have seen how many opportunities there are for improvement I just want to make sure I don't miss any easy fixes. :) -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-28 13:22:42
|
On 8/28/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> We can indeed use cdef for this, but it's rather low level. I wonder
> >> if we
> >> can make a better api for this, maybe something like:
> >>
> >> add_method (...)
> >
> > You and Matthias are solving different problems.
> > Matthias generates new function from the script and than adds it to the
> > class.
>
> Well, not only. In my Maya bindings I'm also doing the same thing as
> Neal, i.e. I have manually written C++ functions that I add as methods
> to some classes using cdef().
It does not different from what I say. You did not feed the
declarations to Py++.
> > You already have function declaration, and the only thing you want to
> > do is to associate it
> > with the class. I think it will take only few hours to implement what
> > you are asking for.
> >
> > cls = mb.class_("X")
> > f = mb.free_function( "addAssign" )
> > cls.add_method( f )
>
> I think this could be a useful feature, couldn't it?
Yes.
> However, in my case I would have to change my project setup a bit as
> Py++ doesn't "see" my manually written functions. I'm not parsing my own
> headers so the query for the free function wouldn't work.
>
> > While it is possible to implement this on top of cdef function, I
> > think it will be a wrong
> > solution. Why? Because next functionality already exists in code creators:
> > 1. keyword arguments ( default values )
> > 2. introducing function type into generated code
> > 3. argument policies ( they will not work on function )
> > 4. warnings
> > 5. class held type and smart pointers registration
>
> But in the above example f is already a "real" declaration that will get
> turned into a "real" code creator, so all the above features could be
> used, couldn't they?
I just wanted to save time :-). I can implement the feature, but it
will take some time.
Do you want to try to implement it?
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-08-28 13:16:12
|
Roman Yakovenko wrote:
>> We can indeed use cdef for this, but it's rather low level. I wonder
>> if we
>> can make a better api for this, maybe something like:
>>
>> add_method (...)
>
> You and Matthias are solving different problems.
> Matthias generates new function from the script and than adds it to the
> class.
Well, not only. In my Maya bindings I'm also doing the same thing as
Neal, i.e. I have manually written C++ functions that I add as methods
to some classes using cdef().
> You already have function declaration, and the only thing you want to
> do is to associate it
> with the class. I think it will take only few hours to implement what
> you are asking for.
>
> cls = mb.class_("X")
> f = mb.free_function( "addAssign" )
> cls.add_method( f )
I think this could be a useful feature, couldn't it?
However, in my case I would have to change my project setup a bit as
Py++ doesn't "see" my manually written functions. I'm not parsing my own
headers so the query for the free function wouldn't work.
> While it is possible to implement this on top of cdef function, I
> think it will be a wrong
> solution. Why? Because next functionality already exists in code creators:
> 1. keyword arguments ( default values )
> 2. introducing function type into generated code
> 3. argument policies ( they will not work on function )
> 4. warnings
> 5. class held type and smart pointers registration
But in the above example f is already a "real" declaration that will get
turned into a "real" code creator, so all the above features could be
used, couldn't they?
- Matthias -
|
|
From: Matthias B. <ba...@ir...> - 2006-08-28 13:10:14
|
Neal Becker wrote:
>> root.Class("X").cdef("__iadd__", "addAssign", return_self())
>
> One of the really cool things about boost::python is that you can not only
> wrap c++ classes, but synthesize new functionality. Specifically, you can
> make python classes that don't have c++ equivalents, or add features to
> python classes that don't exist in the c++ class.
>
> We can indeed use cdef for this, but it's rather low level. I wonder if we
> can make a better api for this, maybe something like:
>
> add_method (...)
Can you elaborate on the '...'? (as this is the interesting part) How
would you like the API to look like?
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-08-28 13:01:25
|
On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > Roman Yakovenko wrote: > > > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > > > >> 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? > > > > > > I don't know why, but I think I prefer to pay this price. I prefer > > code, that I can maintain. Sorry. > > It is probably no surprise that I disagree. The extra 25% performance > seems like a good thing to me. :-). It is not 25%. The original time was 12 minutes. Your optimization brought it to 1 minutes, than my changes brought it to 1.25 minutes. > Why were the extra layers of indirection needed in your implementation? > > In my implementation I just tried to keep everything local to the method > I was optimizing. In that way I thought it was pretty maintainable > because that method was the only place in the code that set or used the > cache value. This still allowed for disabling caching by using a module > level variable to prevent the cache from being set. > > What caused this local encapsulation to be less maintainable? You can not answer the question "what optimization pygccxml does" without scanning the whole source code. pygccxml supports "file by file" compilation mode. When it joins the declarations tree, it have to clear all declaration and type caches. It is very easy to write decl.cache.reset(). While in your case, developer ( me ) has always scan all sources and to find out what attributes should be reset. Another problem is when new "cache value" is introduced. I can bet, that I will forget to add it to all places where I need reset. Thus the software will become buggy. This is just an example to problem my implementation solves. There is new concept in pygccxml "cache" and I want it to be presented in a right way. > > You already achieved x10 improvement. This is a grate result. Lets > > stop here. > > > I don't know if I will ever stop looking for ways to make this code run > faster, but I will probably stop soon so I can just use the code instead > of trying to improve it. Please don't take it personal, without your ideas and work Py++ would not become such powerful and good tool. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-08-28 12:45:22
|
On 8/28/06, Neal Becker <ndb...@gm...> wrote:
> On Friday 25 August 2006 1:06 pm, Matthias Baas wrote:
> > Roman Yakovenko wrote:
> > > On 8/25/06, Neal Becker <ndb...@gm...> wrote:
> > >> Is there a way to add special functions/operators to a class?
> > >>
> > >> For example:
> > >>
> > >> struct X {};
> > >> X& addAssign (X& x1, X const& x2) { return x1; } // silly example
> > >>
> > >> I want this to do:
> > >> .def ("__iadd__", addAssign, return_self<>())
> > >
> > > I think that if you rename addAssign to __iadd__ this will work, but I
> > > am not sure.
> > >
> > > mb.free_function( 'addAssign' ).rename( '__iadd__' )
> >
> > I think this would only work when addAssign() was a member of X.
> >
> > I'm doing such things with the cdef() method of pypp_api which is
> > equivalent to adding a raw def() statement to the class (I just had to
> > name it something else because "def" is already a Python keyword). Usage
> > of cdef is almost identical to Boost.Python's def. The first argument is
> > the Python name, then comes the C/C++ function (as a string), followed
> > by optional policies, args and doc string in arbitrary order. In the
> > above example, it would look like this:
> >
> > root.Class("X").cdef("__iadd__", "addAssign", return_self())
> >
>
> One of the really cool things about boost::python is that you can not only
> wrap c++ classes, but synthesize new functionality. Specifically, you can
> make python classes that don't have c++ equivalents, or add features to
> python classes that don't exist in the c++ class.
>
> We can indeed use cdef for this, but it's rather low level. I wonder if we
> can make a better api for this, maybe something like:
>
> add_method (...)
You and Matthias are solving different problems.
Matthias generates new function from the script and than adds it to the class.
You already have function declaration, and the only thing you want to
do is to associate it
with the class. I think it will take only few hours to implement what
you are asking for.
cls = mb.class_("X")
f = mb.free_function( "addAssign" )
cls.add_method( f )
While it is possible to implement this on top of cdef function, I
think it will be a wrong
solution. Why? Because next functionality already exists in code creators:
1. keyword arguments ( default values )
2. introducing function type into generated code
3. argument policies ( they will not work on function )
4. warnings
5. class held type and smart pointers registration
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-08-28 12:43:22
|
Roman Yakovenko wrote: > On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > >> 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? > > > I don't know why, but I think I prefer to pay this price. I prefer > code, that I can maintain. Sorry. It is probably no surprise that I disagree. The extra 25% performance seems like a good thing to me. Why were the extra layers of indirection needed in your implementation? In my implementation I just tried to keep everything local to the method I was optimizing. In that way I thought it was pretty maintainable because that method was the only place in the code that set or used the cache value. This still allowed for disabling caching by using a module level variable to prevent the cache from being set. What caused this local encapsulation to be less maintainable? > You already achieved x10 improvement. This is a grate result. Lets > stop here. > I don't know if I will ever stop looking for ways to make this code run faster, but I will probably stop soon so I can just use the code instead of trying to improve it. -Allen |
|
From: Neal B. <ndb...@gm...> - 2006-08-28 12:30:16
|
On Friday 25 August 2006 1:06 pm, Matthias Baas wrote:
> Roman Yakovenko wrote:
> > On 8/25/06, Neal Becker <ndb...@gm...> wrote:
> >> Is there a way to add special functions/operators to a class?
> >>
> >> For example:
> >>
> >> struct X {};
> >> X& addAssign (X& x1, X const& x2) { return x1; } // silly example
> >>
> >> I want this to do:
> >> .def ("__iadd__", addAssign, return_self<>())
> >
> > I think that if you rename addAssign to __iadd__ this will work, but I
> > am not sure.
> >
> > mb.free_function( 'addAssign' ).rename( '__iadd__' )
>
> I think this would only work when addAssign() was a member of X.
>
> I'm doing such things with the cdef() method of pypp_api which is
> equivalent to adding a raw def() statement to the class (I just had to
> name it something else because "def" is already a Python keyword). Usage
> of cdef is almost identical to Boost.Python's def. The first argument is
> the Python name, then comes the C/C++ function (as a string), followed
> by optional policies, args and doc string in arbitrary order. In the
> above example, it would look like this:
>
> root.Class("X").cdef("__iadd__", "addAssign", return_self())
>
One of the really cool things about boost::python is that you can not only
wrap c++ classes, but synthesize new functionality. Specifically, you can
make python classes that don't have c++ equivalents, or add features to
python classes that don't exist in the c++ class.
We can indeed use cdef for this, but it's rather low level. I wonder if we
can make a better api for this, maybe something like:
add_method (...)
|
|
From: Roman Y. <rom...@gm...> - 2006-08-28 04:51:28
|
On 8/28/06, Allen Bierbaum <al...@vr...> wrote: > 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? I don't know why, but I think I prefer to pay this price. I prefer code, that I can maintain. Sorry. You already achieved x10 improvement. This is a grate result. Lets stop here. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
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 > > > |
|
From: Roman Y. <rom...@gm...> - 2006-08-27 19:43:24
|
On 8/27/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 8/27/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I had trouble putting it into goodies as an override because it looks
> >> like the method comes in through multiple module aliases. In other
> >> words I haven't found a way to override all the of the uses of the
> >> method.
> >
> >
> > Well, global variable will do the job :-(. Can you implement it?
> >
> How would a global variable fix a symbol alias issue?
def create_identifier_smart( ... )
...
def create_identifier_quick( ... )
...
CREATE_IDENTIFIER_USE_SMART = True
def create_identifier( ... ):
if CREATE_IDENTIFIER_USE_SMART:
...
else:
...
Or another solution is to add function in the same module as create_identifier
def setup_create_identifier( ... ):
replace the reference of create_identifier with another one
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-08-27 19:40:09
|
Roman Yakovenko wrote: > On 8/27/06, Allen Bierbaum <al...@vr...> wrote: > >> I had trouble putting it into goodies as an override because it looks >> like the method comes in through multiple module aliases. In other >> words I haven't found a way to override all the of the uses of the >> method. > > > Well, global variable will do the job :-(. Can you implement it? > How would a global variable fix a symbol alias issue? -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-08-27 19:22:13
|
On 8/27/06, Allen Bierbaum <al...@vr...> wrote: > Roman: > > It looks like about 1/3 of the time is now being spent inside > proceed_single in make_flatten. > > Is there any reason I shouldn't be able to use _make_flatten_generator > instead of make_flatten so I can remove the performance hit of > allocating the memory for such a large list every time make_flatten is > called? Yes, performance reason :-). Last time I tested it, it was very slow. But you can try and report the numbers. P.S. I think that few testers and may be some real code will fail here and there but we can fix it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-08-27 19:19:35
|
On 8/27/06, Allen Bierbaum <al...@vr...> wrote: > I had trouble putting it into goodies as an override because it looks > like the method comes in through multiple module aliases. In other > words I haven't found a way to override all the of the uses of the method. Well, global variable will do the job :-(. Can you implement it? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
23 messages has been excluded from this view by a project administrator.
