emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimize assume(...) away? (agaiin)


From: Eli Zaretskii
Subject: Re: Optimize assume(...) away? (agaiin)
Date: Wed, 09 Oct 2013 20:21:21 +0300

> Date: Wed, 09 Oct 2013 20:43:17 +0400
> From: Dmitry Antipov <address@hidden>
> CC: Stefan Monnier <address@hidden>, 
>  Eli Zaretskii <address@hidden>,
>  Paul Eggert <address@hidden>
> 
> 1) http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00238.html
> 2) http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15565
> 
> 3) Consider non-trivial eassert like:
> 
> eassert ((BUFFERP (it->object)
>            && IT_CHARPOS (*it) == it->bidi_it.charpos
>            && IT_BYTEPOS (*it) == it->bidi_it.bytepos)
>           || (STRINGP (it->object)
>               && IT_STRING_CHARPOS (*it) == it->bidi_it.charpos
>               && IT_STRING_BYTEPOS (*it) == it->bidi_it.bytepos)
>           || (CONSP (it->object) && it->method == GET_FROM_STRETCH))
> 
>    a) It takes some time to check whether there are side effects here;
>    b) If someone change 'struct it' so IT_STRING_CHARPOS (*it)
>       becomes a non-trivial function with side effects, it would be
>       too annoying (and error-prone) to review all easserts.
> 
> Due to 1), 2) and 3) I strongly suggests to redesign eassert
> to avoid any assumptions about its argument expression.

How about simply removing 'assume' from eassert?  

'assume' is primarily an optimization device, and thus important in
production builds of Emacs where optimizations are enabled.  By
contrast, eassert will be defined to nothing in such builds.  So it
sounds like we are at best optimizing a rare, or even non-existing use
case, a.k.a. "premature optimization".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]