Re: dependency tee from c parser entities downto token

[Konrad Eisele <eiselekd@gmail.com>]

On 05/05/2012 12:30 AM, Christopher Li wrote:
> On Fri, May 4, 2012 at 1:53 PM, Konrad Eisele<eiselekd@gmail.com>  wrote:
>> make C=2:
>>
>> original sparse:
>> real    17m54.997s
>> user    15m25.181s
>> sys     2m11.281s
>>
>> decpp-sparse from "git clone git://git.code.sf.net/p/decpp/code decpp "
>> real    18m29.748s
>> user    16m18.155s
>> sys     2m13.221s
>>
>> But decpp is not written with performance in common cases in mind.
>> The 2 runs probably also depend on other factors too.
>> I cant think that 4 bytes extra for each token can have a big impact,
>> if I would implement it that way (it is not in decpp).
>
> The deal breaker is not able to free token list if other program using
> sparse don't need it. I believe that I have an alternative approach
> allow you do want you want while keeping the impact to sparse
> internal small. In my mind, that is straightly better than your
> current patch. I can share more details if you found a missing link.
>
>> I understand. Actually the code to demonstrate is
>> git://git.code.sf.net/p/decpp/code , then do a
>> $make
>> $./shrinkc t1.c
>> That is kind of the goal.
>> And - it does require some  internal structure
>> change. You dont get this kind of functionality
>> for free. You have to be invasive, isnt this
>> something that is obvious?. And in my view, it
>> can come with penalty. The preprocessing stage
>
> That doesn't mean that we should pay any penalty
> for it. Especially I believe there is better alternative
> approach to allow you do what you want and keep
> the API clean. You need to be a little patient here
> to understand my alternative suggestions. I did spend
> some time here to come up with the approach to make
> it works for you and keep myself happy about the internals.
>
> You dismiss the my suggestion too eagerly without
> considering how to make it work. You are pretty much saying,
> "Nah, this is not going to work, I am calling in the big hammers."
> You should at least consider it, point out where you think
> it doesn't work, so that I can provide addition details how
> to make it work. I did notice that I have some detail left out in
> my suggestions, mostly due to time constrain to write it up.
>
> Chris
>

I'm willing to learn, I'll implement your token<pos> scheme,
see the other mail just sent on that subject
-- Konrad