Anybody may help to explain the issue of the source code , next "try-throw-catch" will cost more cpu time than previous one

[f z]

Andrew,

I compile the release version of the test code with VC 6.0 and run it on windows xp sp2 , but it took the same time in every try_throw_catch block ,so perhaps we can do something to improve the preformance 

Miles 


> 发件人: Andrew Haley <aph@redhat.com>
> 主题: Re: Anybody may help to explain the issue of the source code , next "try-throw-catch" will cost more cpu time than previous one
> 收件人: "f z" <zhangjiakouzf@yahoo.com.cn>
> 抄送: gcc-help@gcc.gnu.org
> 日期: 2009,12,周五,12:56上午
> f z wrote:
> > Happy New Year! Haley,
> 
> And a Happy New Year to you.
> 
> > Thanks for your help!
> > 
> > In your result , there isn't any variation in the
> time taken.
> > 
> > My test code can be like this :
> > 
> > while(1){
> >  try_throw_catch_block(0); // it takes about 133xxxxx
> every time
> >  try_throw_catch_block(1); // it takes about 148xxxxx
> every time
> >  try_throw_catch_block(2); // it takes about 158xxxxx
> every time
> >  try_throw_catch_block(3); // it takes about 172xxxxx
> every time 
> > }
> 
> > In my opinion , next "try_throw_catch" in
> writing order will takes more cpu time than the previous
> one.
> > 
> > Then , I will use oprofile to check it. 
> 
> Yes, I see the same result as you.
> 
> I think I might know what is happening.  When a throw is
> caught, there
> is a search for the catch region.
> 
> _Unwind_IteratePhdrCallback searches for the eh_frame that
> contains
> the PC we're looking for.  There is a binary search for
> the catch
> region.  Like all binary searches, this is not constant
> time, so I
> suspect that's what we're seeing.
> 
> Andrew.


      ___________________________________________________________ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/