[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Óscar Fuentes |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Mon, 21 Feb 2022 01:22:08 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think I'm just trying to get some sort of handle on how much the code
>> has slowed down because of EQ. Obviously, making EQ into a function
>> (rather than an inline function) will have distorted things, but it
>> seems the easiest way of measuring something at the moment.
>
> I understand, but it's still going to be hard to figure out what the
> result means. Let's say you find that the new non-inlined EQ is 20%
> slower than the old non-inlined EQ, what does it tell us about the
> inlined versions?
>
> It's quite possible that more than 50% of the time spent in the
> non-inlined EQ is spent in the "function call overhead" (the jumps
> themselves, the forced placement into specific registers, the need to
> reify a condition code into a boolean stored in a register, the
> impossibility to move code around the call to EQ because the compiler
> doesn't know it's a pure function, ...)?
For those and more reasons it is useless to directly measure changes to
small utility functions in complex applications, even to non-inline
ones. The results can be highly misleading.
If you want to know the impact of such a change, the correct method is
to measure representative instances of real-world cases.
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/06
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, David Engster, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, David Engster, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Óscar Fuentes <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Óscar Fuentes, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/21
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Óscar Fuentes, 2022/02/21
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/06