* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 13:05 ` Eli Zaretskii
@ 2014-02-21 7:43 ` Stefan-W. Hahn
2014-02-23 18:04 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-21 7:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
[-- Attachment #1: Type: text/plain, Size: 6275 bytes --]
Mail von Eli Zaretskii, Sat, 22 Feb 2014 at 15:05:26 +0200:
Good morning,
> > (I wasn't able to compile it myself on windows; I tried it, but I wasn't
> > able to find all prerequisites. This is really easier on linux.)
>
> Latest versions compile like on GNU/Linux, you just need to create a
> suitable environment first, using the advice in nt/INSTALL.
(I'm on commit 02825295f from 2014-02-22.)
I tried to install MinGW/MSYS as described in nt/INSTALL. I started msys.bat
and configured with "./configure --prefix=/d/bin/emacs-mingw" .It configured well
but didn't compile:
Configured for `i686-pc-mingw32'.
Where should the build process find the source code? .
What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2 -gdwarf-2
Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? w32
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use -lpng? no
Does Emacs use -lrsvg-2? yes
Does Emacs use imagemagick? yes
Does Emacs support sound? yes
Does Emacs use -lgpm? no
Does Emacs use -ldbus? yes
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use a file notification library? yes -lgio (gfile)
Does Emacs use access control lists? yes
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? yes
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? no
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs directly use zlib? no
Does Emacs use toolkit scroll bars? yes
$ make
[ -r "src/config.in" ] || ( cd . && autoheader )
cd nt && make all \
CC='gcc -std=gnu99' CFLAGS='-g3 -O2 -gdwarf-2' CPPFLAGS='-mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt
/inc' \
LDFLAGS='' MAKE='make'
make[1]: Entering directory `/d/home/hs/src/emacs.git/nt'
windres -I . -O coff -o emacs.res ./emacs.rc
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./runemacs.c emacs.res -mwindows \
-o runemacs.exe
./runemacs.c: In function `WinMain':
./runemacs.c:74: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./addpm.c -lole32 -luuid -o addpm.exe
./addpm.c: In function `add_registry':
./addpm.c:134: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./cmdproxy.c -o cmdproxy.exe
./cmdproxy.c: In function `make_absolute':
./cmdproxy.c:288: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./ddeclient.c -o ddeclient.exe
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./addsection.c -o addsection.exe
In file included from /usr/include/sys/fcntl.h:164,
from /usr/include/fcntl.h:14,
from ./addsection.c:26:
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:90: error: parse error before "st_ino"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:96: error: parse error before "st_size"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:103: error: parse error before '}' token
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:108: error: parse error before "_dev_t"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:110: error: parse error before "st_mode"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:110: error: conflicting types for 'st_mode'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:92: error: previous declaration of 'st_mode' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:112: error: conflicting types for 'st_uid'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:94: error: previous declaration of 'st_uid' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:113: error: conflicting types for 'st_gid'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:95: error: previous declaration of 'st_gid' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:114: error: parse error before "st_rdev"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:114: error: conflicting types for 'st_rdev'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:97: error: previous declaration of 'st_rdev' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:115: error: conflicting types for 'st_size'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:96: error: previous declaration of 'st_size' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:120: error: parse error before '}' token
make[1]: *** [addsection.exe] Error 1
make[1]: Leaving directory `/d/home/hs/src/emacs.git/nt'
make: *** [nt] Error 2
gcc --version gives: gcc (GCC) 3.4.4 (msys special).
I attach the whole configure process data.
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
[-- Attachment #2: errors.txt --]
[-- Type: text/plain, Size: 24779 bytes --]
hs@LAPTOP ~/src/emacs.git
$ ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
You can now run `./configure'.
hs@LAPTOP ~/src/emacs.git
$ ./configure --prefix=/d/bin/emacs-mingw
checking for xcrun... no
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -I ./nt/inc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for Minix Amsterdam compiler... no
checking for ar... ar
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... no
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... no
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... unknown
checking for _LARGE_FILES value needed for large files... unknown
checking for gcc -I ./nt/inc option to accept ISO C99... -std=gnu99
checking for gcc -I ./nt/inc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99
checking whether gcc -I ./nt/inc -std=gnu99 accepts -g3 -O2... yes
checking whether the compiler is clang... no
checking whether ln -s works for files in the same directory... yes
checking for install-info... /d/cygwin/bin/install-info
checking for gzip... /bin/gzip
checking for makeinfo... /d/cygwin/bin/makeinfo
checking for -znocombreloc... no
checking whether addresses are sanitized... no
checking for pkg-config... /d/cygwin/bin/pkg-config
checking for machine/soundcard.h... no
checking for sys/soundcard.h... yes
checking for soundcard.h... no
checking for _oss_ioctl in -lossaudio... no
checking for alsa >= 1.0.0... no
checking for sys/systeminfo.h... no
checking for coff.h... no
checking for pty.h... no
checking for sys/resource.h... yes
checking for sys/utsname.h... yes
checking for pwd.h... no
checking for utmp.h... yes
checking for util.h... no
checking for sys/socket.h... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) no
checking for sys/param.h... yes
checking for pthread.h... yes
checking for malloc/malloc.h... no
checking for maillock.h... no
checking for sys/un.h... yes
checking for dirent.h... yes
checking for execinfo.h... no
checking for stdio_ext.h... no
checking for getopt.h... (cached) no
checking for sys/time.h... yes
checking for wchar.h... yes
checking for stdint.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for sys/select.h... yes
checking for sys/stat.h... (cached) no
checking for utime.h... yes
checking if personality LINUX32 can be set... no
checking for term.h... no
checking whether time.h and sys/time.h may both be included... yes
checking whether sys_siglist is declared... no
checking whether __sys_siglist is declared... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for net/if.h... yes
checking for ifaddrs.h... no
checking for net/if_dl.h... no
checking for struct ifreq.ifr_flags... yes
checking for struct ifreq.ifr_hwaddr... yes
checking for struct ifreq.ifr_netmask... yes
checking for struct ifreq.ifr_broadaddr... yes
checking for struct ifreq.ifr_addr... yes
checking for struct ifreq.ifr_addr.sa_len... no
checking whether we are using GNU Make... yes
checking whether gcc understands -MMD -MF... yes
checking for long file names... yes
checking for X... no
checking whether Windows API headers are recent enough... yes
checking for windres... windres
checking whether malloc is Doug Lea style... no
checking sys/vlimit.h usability... no
checking sys/vlimit.h presence... no
checking for sys/vlimit.h... no
checking for data_start... no
checking for getpagesize... yes
checking for working mmap... no
checking for dnet_ntoa in -ldnet... no
checking for main in -lXbsd... no
checking for pthread_atfork in -lpthread... no
checking for cma_open in -lpthreads... no
checking for librsvg-2.0 >= 2.11.0... yes CFLAGS='-D_REENTRANT -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.
0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/libpng15 -I/usr/include/pixman-1 -I/usr/include/freetype
2 ' LIBS='-lrsvg-2 -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lffi -lpixman-1 -lfontconfig -lexpat -lfreetype
-lbz2 -lpng15 -lm -lz -lxcb-shm -lxcb-render -lXrender -lXext -lglib-2.0 -lintl -liconv -lpcre -lX11 -lxcb -lXau -lXdmcp '
checking for Wand >= 6.2.8 Wand != 6.8.2... yes CFLAGS='-fopenmp -I/usr/include/ImageMagick ' LIBS='-lMagickWand -lMagickCore '
checking for MagickExportImagePixels... no
checking for MagickMergeImageLayers... no
checking for dbus-1 >= 1.0... yes CFLAGS='-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include ' LIBS='-ldbus-1 -lpthread -lrt '
checking for dbus_watch_get_unix_fd... no
checking for dbus_type_is_valid... no
checking for dbus_validate_bus_name... no
checking for dbus_validate_path... no
checking for dbus_validate_interface... no
checking for dbus_validate_member... no
checking for lgetfilecon in -lselinux... no
checking for gnutls >= 3.0.0... yes CFLAGS='-I/usr/include/p11-kit-1 ' LIBS='-L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -
lp11-kit -lz '
checking windows.h usability... no
checking windows.h presence... yes
configure: WARNING: windows.h: present but cannot be compiled
configure: WARNING: windows.h: check for missing prerequisite headers?
configure: WARNING: windows.h: see the Autoconf documentation
configure: WARNING: windows.h: section "Present But Cannot Be Compiled"
configure: WARNING: windows.h: proceeding with the compiler's result
checking for windows.h... no
checking for gio-2.0 >= 2.24... yes CFLAGS='-D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include ' LIBS='-lgio-2.0 -lz
-lgmodule-2.0 -lgobject-2.0 -lffi -lglib-2.0 -lintl -liconv -lpcre '
checking for X11/xpm.h... no
checking jerror.h usability... no
checking jerror.h presence... no
checking for jerror.h... no
checking png.h usability... no
checking png.h presence... no
checking for png.h... no
checking for library containing inflateEnd... no
checking tiffio.h usability... no
checking tiffio.h presence... no
checking for tiffio.h... no
checking gif_lib.h usability... no
checking gif_lib.h presence... no
checking for gif_lib.h... no
checking gpm.h usability... no
checking gpm.h presence... no
checking for gpm.h... no
checking for libxml-2.0 > 2.6.17... yes CFLAGS='-I/usr/include/libxml2 ' LIBS='-lxml2 -lz -liconv -lm '
checking whether netdb declares h_errno... (cached) yes
checking for maillock in -lmail... no
checking for maillock in -llockfile... no
checking for liblockfile.so... no
checking for accept4... no
checking for gethostname... (cached) yes
checking for getrusage... no
checking for get_current_dir_name... no
checking for lrand48... no
checking for select... (cached) yes
checking for getpagesize... (cached) yes
checking for setlocale... no
checking for getrlimit... no
checking for setrlimit... no
checking for shutdown... (cached) yes
checking for getaddrinfo... no
checking for strsignal... no
checking for setitimer... (cached) yes
checking for sendto... (cached) yes
checking for recvfrom... (cached) yes
checking for getsockname... (cached) yes
checking for getpeername... (cached) yes
checking for getifaddrs... no
checking for freeifaddrs... no
checking for gai_strerror... no
checking for getline... no
checking for getdelim... no
checking for sync... no
checking for getpwent... no
checking for endpwent... no
checking for getgrent... no
checking for endgrent... no
checking for touchlock... no
checking for cfmakeraw... no
checking for cfsetspeed... no
checking for copysign... no
checking for __executable_start... no
checking for log2... no
checking for random... (cached) yes
checking for rint... no
checking for __builtin_unwind_init... no
checking for _LARGEFILE_SOURCE value needed for large files... unknown
checking for grantpt... no
checking for getpt... no
checking for posix_openpt... no
checking for library containing tputs... none required
checking for res_init with -lresolv... no
checking valgrind/valgrind.h usability... no
checking valgrind/valgrind.h presence... no
checking for valgrind/valgrind.h... no
checking for tzset... no
checking for readlinkat... (cached) yes
checking for faccessat... (cached) yes
checking for fcntl... (cached) yes
checking for fdopendir... (cached) not-needed
checking for fstatat... (cached) yes
checking for fsync... (cached) yes
checking for gettimeofday... no
checking for nanotime... no
checking for lstat... (cached) yes
checking for mkostemp... (cached) yes
checking for pipe2... (cached) yes
checking for pselect... (cached) yes
checking for pthread_sigmask... (cached) yes
checking for fchmod... no
checking for readlink... (cached) yes
checking for strtoimax... no
checking for strtoumax... no
checking for symlink... (cached) yes
checking for localtime_r... no
checking for futimes... no
checking for futimesat... no
checking for futimens... no
checking for utimensat... no
checking for lutimes... no
checking for getdtablesize... no
checking for secure_getenv... no
checking whether localtime caches TZ... no
checking for socket... (cached) yes
checking netinet/in.h usability... no
checking netinet/in.h presence... yes
configure: WARNING: netinet/in.h: present but cannot be compiled
configure: WARNING: netinet/in.h: check for missing prerequisite headers?
configure: WARNING: netinet/in.h: see the Autoconf documentation
configure: WARNING: netinet/in.h: section "Present But Cannot Be Compiled"
configure: WARNING: netinet/in.h: proceeding with the compiler's result
checking for netinet/in.h... no
checking for pid_t... no
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... no
checking for vfork... no
checking for snprintf... no
checking whether GLib is linked in... no
checking for nl_langinfo and CODESET... (cached) yes
checking for mbstate_t... no
checking for C restricted array declarations... no
checking for _setjmp... no
checking for sigsetjmp... no
checking for usable FIONREAD... yes
checking for usable SIGIO... no
checking for working alloca.h... no
checking for alloca... yes
checking for unsigned long long int... yes
checking whether byte ordering is bigendian... no
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking whether strtold conforms to C99... no
checking if environ is properly declared... no
checking for complete errno.h... no
checking for EMULTIHOP value... yes
checking for ENOLINK value... yes
checking for EOVERFLOW value... no
checking for mode_t... yes
checking whether fdatasync is declared... no
checking for st_dm_mode in struct stat... no
checking whether strmode is declared... no
checking whether lstat correctly handles trailing slash... (cached) yes
checking for getopt.h... (cached) no
checking whether getenv is declared... yes
checking for C/C++ restrict keyword... __restrict
checking for struct timeval... yes
checking for wide-enough struct timeval.tv_sec member... (cached) yes
checking for long long int... yes
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... no
checking sys/inttypes.h presence... no
checking for sys/inttypes.h... no
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking for bit size of ptrdiff_t... 32
checking for bit size of size_t... 32
checking for bit size of sig_atomic_t... 32
checking for bit size of wchar_t... 16
checking for bit size of wint_t... 32
checking whether sig_atomic_t is signed... yes
checking whether wchar_t is signed... no
checking whether wint_t is signed... no
checking for ptrdiff_t integer literal suffix...
checking for size_t integer literal suffix... u
checking for sig_atomic_t integer literal suffix...
checking for wchar_t integer literal suffix... no
checking for wint_t integer literal suffix... u
checking for 64-bit off_t... no
checking whether memrchr is declared... no
checking whether alarm is declared... (cached) yes
checking whether <sys/select.h> is self-contained... yes
checking for sigset_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for wchar_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... no
checking whether tzname is declared... yes
checking for tzname... yes
checking for struct tm.tm_gmtoff... no
checking whether strtoimax is declared... yes
checking whether strtoumax is declared... yes
checking whether stat file-mode macros are broken... yes
checking for struct timespec in <time.h>... yes
checking whether unsetenv is declared... (cached) yes
checking whether the utimes function works... no
checking for struct utimbuf... yes
checking type of array argument to getgroups... gid_t
checking byteswap.h usability... no
checking byteswap.h presence... no
checking for byteswap.h... no
checking for library containing clock_gettime... no
checking for clock_gettime... no
checking for clock_settime... no
checking whether dup2 works... (cached) yes
checking whether fcntl handles F_DUPFD correctly... (cached) yes
checking whether fcntl understands F_DUPFD_CLOEXEC... (cached) yes
checking for fdatasync... (cached) yes
checking whether fdopendir is declared... no
checking whether fdopendir works... (cached) no-but-not-needed-so-yes
checking for __fpending... no
checking how to determine the number of pending output bytes on a stream... fp->_p - fp->_bf._base
checking whether fstatat (..., 0) works... (cached) yes
checking for getloadavg... (cached) yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking whether getloadavg is declared... no
checking sys/timeb.h usability... yes
checking sys/timeb.h presence... yes
checking for sys/timeb.h... yes
checking for _ftime... yes
checking for memrchr... no
checking for working mktime... (cached) yes
checking whether signature of pselect conforms to POSIX... (cached) yes
checking whether pselect detects invalid fds... (cached) yes
checking whether pthread_sigmask works without -lpthread... yes
checking whether pthread_sigmask returns error numbers... (cached) yes
checking whether pthread_sigmask unblocks signals correctly... (cached) not relevant
checking for putenv compatible with GNU and SVID... (cached) yes
checking sys/acl.h usability... yes
checking sys/acl.h presence... yes
checking for sys/acl.h... yes
checking for library containing acl_get_file... (cached) none required
checking for acl_get_file... (cached) yes
checking for acl_get_fd... no
checking for acl_set_file... (cached) yes
checking for acl_set_fd... no
checking for acl_free... (cached) yes
checking for acl_from_mode... no
checking for acl_from_text... (cached) yes
checking for acl_delete_def_file... no
checking for acl_extended_file... no
checking for acl_delete_fd_np... no
checking for acl_delete_file_np... no
checking for acl_copy_ext_native... no
checking for acl_create_entry_np... no
checking for acl_to_short_text... no
checking for acl_free_text... no
checking for working acl_get_file... (cached) yes
checking acl/libacl.h usability... no
checking acl/libacl.h presence... no
checking for acl/libacl.h... no
checking for acl_entries... no
checking for ACL_FIRST_ENTRY... no
checking for ACL_TYPE_EXTENDED... no
checking whether readlink signature is correct... no
checking whether readlink handles trailing slash correctly... (cached) yes
checking for sig2str... no
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking for socklen_t... yes
checking for ssize_t... yes
checking for struct stat.st_atim.tv_nsec... no
checking for struct stat.st_atimespec.tv_nsec... no
checking for struct stat.st_atimensec... no
checking for struct stat.st_atim.st__tim.tv_nsec... no
checking for struct stat.st_birthtimespec.tv_nsec... no
checking for struct stat.st_birthtimensec... no
checking for struct stat.st_birthtim.tv_nsec... no
checking for working stdalign.h... yes
checking for va_copy... yes
checking whether NULL can be used in arbitrary expressions... yes
checking whether strtoll is declared... no
checking whether strtoull is declared... no
checking whether symlink handles trailing slash correctly... (cached) yes
checking whether <sys/select.h> is self-contained... (cached) yes
checking for nlink_t... no
checking whether localtime_r is declared... yes
checking for library containing timer_settime... no
checking for timer_settime... no
checking for unsetenv... (cached) yes
checking for unsetenv() return type... (cached) int
checking whether unsetenv obeys POSIX... (cached) yes
checking whether stat handles trailing slashes on directories... (cached) yes
checking whether stat handles trailing slashes on files... (cached) yes
checking for strtoll... no
checking for strtoull... no
Configured for `i686-pc-mingw32'.
Where should the build process find the source code? .
What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2 -gdwarf-2
Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? w32
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use -lpng? no
Does Emacs use -lrsvg-2? yes
Does Emacs use imagemagick? yes
Does Emacs support sound? yes
Does Emacs use -lgpm? no
Does Emacs use -ldbus? yes
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use a file notification library? yes -lgio (gfile)
Does Emacs use access control lists? yes
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? yes
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? no
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs directly use zlib? no
Does Emacs use toolkit scroll bars? yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating lib-src/Makefile
config.status: creating oldXMenu/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating src/Makefile
config.status: creating lwlib/Makefile
config.status: creating lisp/Makefile
config.status: creating leim/Makefile
config.status: creating nextstep/Makefile
config.status: creating nt/Makefile
config.status: creating test/automated/Makefile
config.status: creating admin/unidata/Makefile
config.status: creating admin/grammars/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing src/epaths.h commands
config.status: executing src/.gdbinit commands
hs@LAPTOP ~/src/emacs.git
$ make
[ -r "src/config.in" ] || ( cd . && autoheader )
cd nt && make all \
CC='gcc -std=gnu99' CFLAGS='-g3 -O2 -gdwarf-2' CPPFLAGS='-mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt
/inc' \
LDFLAGS='' MAKE='make'
make[1]: Entering directory `/d/home/hs/src/emacs.git/nt'
windres -I . -O coff -o emacs.res ./emacs.rc
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./runemacs.c emacs.res -mwindows \
-o runemacs.exe
./runemacs.c: In function `WinMain':
./runemacs.c:74: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./addpm.c -lole32 -luuid -o addpm.exe
./addpm.c: In function `add_registry':
./addpm.c:134: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./cmdproxy.c -o cmdproxy.exe
./cmdproxy.c: In function `make_absolute':
./cmdproxy.c:288: warning: implicit declaration of function `alloca'
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./ddeclient.c -o ddeclient.exe
gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
./addsection.c -o addsection.exe
In file included from /usr/include/sys/fcntl.h:164,
from /usr/include/fcntl.h:14,
from ./addsection.c:26:
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:90: error: parse error before "st_ino"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:96: error: parse error before "st_size"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:103: error: parse error before '}' token
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:108: error: parse error before "_dev_t"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:110: error: parse error before "st_mode"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:110: error: conflicting types for 'st_mode'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:92: error: previous declaration of 'st_mode' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:112: error: conflicting types for 'st_uid'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:94: error: previous declaration of 'st_uid' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:113: error: conflicting types for 'st_gid'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:95: error: previous declaration of 'st_gid' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:114: error: parse error before "st_rdev"
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:114: error: conflicting types for 'st_rdev'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:97: error: previous declaration of 'st_rdev' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:115: error: conflicting types for 'st_size'
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:96: error: previous declaration of 'st_size' was here
/d/home/hs/src/emacs.git/nt/inc/sys/stat.h:120: error: parse error before '}' token
make[1]: *** [addsection.exe] Error 1
make[1]: Leaving directory `/d/home/hs/src/emacs.git/nt'
make: *** [nt] Error 2
hs@LAPTOP ~/src/emacs.git
$
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
@ 2014-02-21 12:16 Stefan-W. Hahn
2014-02-21 12:32 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-21 12:16 UTC (permalink / raw)
To: 16830
Good day,
I have measured a massive slow down for emacs24 on windows. I struggled
while using org-mode columnview, which takes for a short table several
minutes compared to a second with an older versino of emacs.
I tried to dig it down:
Running on an Core I7 Laptop with Windows 7/64 bit,
starting "emacs -q"
I got the following times (elp measurement) for the org-mode function
org-goto-line:
Emacs 24.3.1 is ok, on Emacs 24.3.50 (I tested
https://www.dropbox.com/sh/3pgcb3iiy8s9irl/77pwM1O-5K/emacs-20140217-r116465-bin-i386.zip
) got a slow down of factor 10!!
org-goto-line (24.3.1)
test-org-goto-line 1 0.2 0.2
forward-line 10000 0.0640000000 6.40...e-006
widen 10000 0.003 3e-007
goto-char 10001 0.002 1.99...e-007
org-forward-line with narrow (24.3.1)
test-forward-line 1 0.042 0.042
forward-line 10000 0.003 3e-007
goto-char 1 0.0 0.0
org-forward-line without narrow (24.3.1)
test-forward-line 1 0.046 0.046
forward-line 10000 0.007 7e-007
goto-char 1 0.0 0.0
org-goto-line (24.3.50.1)
test-org-goto-line 1 2.141 2.141
forward-line 10000 1.8479999999 0.0001847999
goto-char 10001 0.006 5.99...e-007
widen 10000 0.005 5e-007
org-forward-line with narrow (24.3.50.1)
test-forward-line 1 0.102 0.102
forward-line 10000 0.0160000000 1.60...e-006
goto-char 1 0.0 0.0
org-forward-line without narrow (24.3.50.1)
test-forward-line 1 0.125 0.125
forward-line 10000 0.005 5e-007
goto-char 1 0.0 0.0
Problem seemss to be forward-line.
Tested with following test case:
#+BEGIN_SRC elisp
(defsubst my-org-goto-line (N)
(save-restriction
(widen)
(goto-char (point-min))
(forward-line (1- N))))
(defun test-org-goto-line ()
(with-temp-buffer
(open-line 10000)
(goto-char (point-min))
(narrow-to-region (point-min) (point-max))
(dotimes (i 10000)
(my-org-goto-line i)
)
)
)
(defun test-forward-line (with-narrow)
(with-temp-buffer
(open-line 10000)
(goto-char (point-min))
(if with-narrow
(narrow-to-region (point-min) (point-max)))
(dotimes (i 10000)
(forward-line 1)
)
)
)
(defvar test-buffer nil)
(defun test-performance/org-goto-line ()
(interactive)
(elp-instrument-list '(test-org-goto-line forward-line goto-char widen))
(test-org-goto-line)
(let ((elp-recycle-buffers-p nil)
rc)
(elp-results)
(setq rc (buffer-string))
(kill-buffer)
(with-current-buffer test-buffer
(insert "org-goto-line ("
emacs-version
")\n")
(insert rc "\n"))
)
(elp-restore-all)
)
(defun test-performance/forward-line (with-narrow)
(interactive)
(elp-instrument-list '(test-forward-line forward-line goto-char widen))
(test-forward-line with-narrow)
(let ((elp-recycle-buffers-p nil)
rc)
(elp-results)
(setq rc (buffer-string))
(kill-buffer)
(with-current-buffer test-buffer
(insert (format "org-forward-line %s (" (if with-narrow "with narrow" "without narrow"))
emacs-version
")\n")
(insert rc "\n")))
(elp-restore-all)
)
(defun test-performance ()
(interactive)
(setq test-buffer (generate-new-buffer "*Performance*"))
(test-performance/org-goto-line)
(test-performance/forward-line t)
(test-performance/forward-line nil)
(pop-to-buffer test-buffer))
#+END:
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-21 12:16 bug#16830: [Bug] 24.3.50; massive slow down in forward-line Stefan-W. Hahn
@ 2014-02-21 12:32 ` Eli Zaretskii
2014-02-21 15:51 ` Stefan-W. Hahn
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-21 12:32 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
> Date: Fri, 21 Feb 2014 13:16:07 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
>
> I have measured a massive slow down for emacs24 on windows. I struggled
> while using org-mode columnview, which takes for a short table several
> minutes compared to a second with an older versino of emacs.
>
> I tried to dig it down:
>
> Running on an Core I7 Laptop with Windows 7/64 bit,
> starting "emacs -q"
>
> I got the following times (elp measurement) for the org-mode function
> org-goto-line:
>
> Emacs 24.3.1 is ok, on Emacs 24.3.50 (I tested
> https://www.dropbox.com/sh/3pgcb3iiy8s9irl/77pwM1O-5K/emacs-20140217-r116465-bin-i386.zip
> ) got a slow down of factor 10!!
Does this happen with any Org file, even small ones?
If not, perhaps you could show a file with which you see this.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-21 12:32 ` Eli Zaretskii
@ 2014-02-21 15:51 ` Stefan-W. Hahn
2014-02-21 17:50 ` Stefan Monnier
0 siblings, 1 reply; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-21 15:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
Mail von Eli Zaretskii, Fri, 21 Feb 2014 at 14:32:30 +0200:
Hello,
> > Emacs 24.3.1 is ok, on Emacs 24.3.50 (I tested
> > https://www.dropbox.com/sh/3pgcb3iiy8s9irl/77pwM1O-5K/emacs-20140217-r116465-bin-i386.zip
> > ) got a slow down of factor 10!!
>
> Does this happen with any Org file, even small ones?
No.
My org-file is around 1.5 MiB. I make a columnview of a subtree, which
is around 28 KiB. If I put this subtree in a standalone file it's faster.
But it is a change between the versions.
> If not, perhaps you could show a file with which you see this.
No, sorry.
Complete measurements:
The org-mode file is in sum 1.5 MiB, the subtree in which I produce
a table columnview is around 28 KiB.
Noticable is that in case of big file org-goto-line is called 54
times with extremly different runtime:
emacs 24.3.1:
org-goto-line 54 0.0240000000 0.0004444444
emacs 24.3.50.1
org-goto-line 54 110.9 2.0537037037
In contrast this function is not called when rebuilding the table
in a small file case.
#+BEGIN_QUOTE
C-c C-c on subtree in big file.
GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
Org-mode version 8.2.5h (release_8.2.5h-633-gec0998 @ d:/home/hs/.emacs-lisp/org-mode/)
elp-instrument-packages org-columns
org-columns-capture-view 1 0.423 0.423
org-columns 1 0.168 0.168
org-columns-display-here 54 0.0150000000 0.0002777777
org-columns-cleanup-item 54 0.003 5.55...e-005
org-columns-new-overlay 216 0.003 1.38...e-005
org-columns-remove-overlays 2 0.001 0.0005
org-columns-compute-all 1 0.001 0.001
org-columns-quit 1 0.001 0.001
org-columns-goto-top-level 1 0.0 0.0
org-columns-get-format 1 0.0 0.0
org-columns-compact-links 54 0.0 0.0
org-columns-add-ellipses 162 0.0 0.0
org-columns-get-autowidth-alist 1 0.0 0.0
org-columns-compile-format 1 0.0 0.0
org-columns-display-here-title 1 0.0 0.0
elp-instrument-packages org
org-ctrl-c-ctrl-c 1 0.718 0.718
org-update-dblock 1 0.71 0.71
org-dblock-write:columnview 1 0.67 0.67
org-columns-capture-view 1 0.428 0.428
org-columns 1 0.222 0.222
org-entry-properties 54 0.1480000000 0.0027407407
org-element--cache-sync 2 0.0740000000 0.0370000000
org-get-category 54 0.051 0.0009444444
org-refresh-category-properties 1 0.051 0.051
org-get-tags-at 54 0.0390000000 0.0007222222
org-element--cache-compare 7894 0.039 4.94...e-006
org-up-heading-safe 251 0.0350000000 0.0001394422
org-end-of-subtree 13 0.0260000000 0.0020000000
org-goto-line 54 0.0240000000 0.0004444444
org-element--cache-record-change 81 0.0230000000 0.0002839506
org-get-property-block 110 0.0200000000 0.0001818181
org-columns-display-here 54 0.0160000000 0.0002962962
org-entry-get 58 0.0150000000 0.0002586206
org-entry-blocked-p 54 0.0130000000 0.0002407407
org-element--cache-before-change 82 0.008 9.75...e-005
org-back-to-heading 906 0.008 8.83...e-006
org-babel-execute-src-block-maybe 1 0.007 0.007
org-babel-where-is-src-block-head 1 0.007 0.007
org-babel-execute-maybe 1 0.007 0.007
org-babel-execute-safely-maybe 1 0.007 0.007
org-columns-new-overlay 216 0.006 2.77...e-005
org-table-align 1 0.006 0.006
org-outline-level 461 0.004 8.67...e-006
org-before-first-heading-p 56 0.003 5.35...e-005
org-prepare-dblock 1 0.003 0.003
org-find-entry-with-id 1 0.003 0.003
org-activate-footnote-links 2 0.002 0.001
org-columns-quit 1 0.002 0.002
org-footnote-next-reference-or-definition 2 0.002 0.001
org-columns-goto-top-level 1 0.001 0.001
org-get-tags-string 54 0.001 1.85...e-005
org-element-context 1 0.001 0.001
org-columns-remove-overlays 2 0.001 0.0005
org-element--current-element 2 0.001 0.0005
org-element-at-point 1 0.001 0.001
org-columns-get-autowidth-alist 1 0.001 0.001
org-split-string 165 0.001 6.06...e-006
org-remove-uninherited-tags 161 0.001 6.21...e-006
org-entry-get-with-inheritance 2 0.001 0.0005
org-font-lock-add-tag-faces 2 0.0 0.0
org-fontify-entities 2 0.0 0.0
org-columns-cleanup-item 54 0.0 0.0
org-table-begin 1 0.0 0.0
org-columns-get-format 1 0.0 0.0
org-reduced-level 54 0.0 0.0
org-quote-vert 162 0.0 0.0
org-element-cache-get 3 0.0 0.0
org-table-goto-column 1 0.0 0.0
org-columns-compact-links 54 0.0 0.0
org-activate-code 2 0.0 0.0
org-babel-get-inline-src-block-matches 1 0.0 0.0
org-string-width 165 0.0 0.0
org-table-end 1 0.0 0.0
org-babel-lob-execute-maybe 1 0.0 0.0
org-element--cache-mapc 2 0 0.0
org-listtable-to-string 1 0.0 0.0
org-columns-add-ellipses 162 0.0 0.0
org-string-match-p 2 0.0 0.0
org-delete-all 161 0.0 0.0
org-do-latex-and-related 2 0.0 0.0
org-fontify-meta-lines-and-blocks-1 2 0.0 0.0
org-verify-version 1 0.0 0.0
org-set-local 6 0.0 0.0
org-font-lock-hook 2 0.0 0.0
org-fontify-macros 2 0.0 0.0
org-element--collect-affiliated-keywords 2 0.0 0.0
org-raise-scripts 2 0.0 0.0
org-element-property 1 0.0 0.0
org-before-change-function 82 0.0 0.0
org-font-lock-add-priority-faces 2 0.0 0.0
org-activate-angle-links 2 0.0 0.0
org-get-limited-outline-regexp 168 0.0 0.0
org-remove-tabs 54 0.0 0.0
org-string-nw-p 2 0.0 0.0
org-trim 110 0.0 0.0
org-update-property-plist 2 0.0 0.0
org-columns-compute-all 1 0.0 0.0
org-element-paragraph-parser 1 0.0 0.0
org-add-prop-inherited 323 0.0 0.0
org-at-table-p 1 0.0 0.0
org-remove-if 2 0.0 0.0
org-activate-target-links 2 0.0 0.0
org-item-re 1 0.0 0.0
org-activate-bracket-links 2 0.0 0.0
org-hide-wide-columns 2 0.0 0.0
org-element-dynamic-block-parser 1 0.0 0.0
org-get-level-face 54 0.0 0.0
org-activate-dates 2 0.0 0.0
org-babel-hash-at-point 1 0.0 0.0
org-add-props 56 0.0 0.0
org-remove-font-lock-display-properties 2 0.0 0.0
org-unfontify-region 2 0.0 0.0
org-at-heading-p 59 0.0 0.0
org-not-nil 2 0.0 0.0
org-element-cache-put 2 0.0 0.0
org-columns-compile-format 1 0.0 0.0
org-table-current-column 1 0.0 0.0
org-overlay-display 216 0.0 0.0
org-fontify-drawers 2 0.0 0.0
org-beginning-of-dblock 1 0.0 0.0
org-babel-lob-get-info 1 0.0 0.0
org-activate-tags 2 0.0 0.0
org-element-type 1 0.0 0.0
org-activate-plain-links 2 0.0 0.0
org-do-emphasis-faces 2 0.0 0.0
org-fontify-meta-lines-and-blocks 2 0.0 0.0
org-columns-display-here-title 1 0.0 0.0
org-add-hook 1 0.0 0.0
#+END_QUOTE
#+BEGIN_QUOTE
C-c C-c on subtree in big file.
GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-01-19 on LEG570
Org-mode version 8.2.5h (release_8.2.5h-633-gec0998 @ d:/home/hs/.emacs-lisp/org-mode/)
emacs-20140217-r116465-bin-i386.zip
org-columns 1 215.017 215.017
org-columns-capture-view 1 1.512 1.512
org-columns-display-here 54 0.0420000000 0.0007777777
org-columns-remove-overlays 2 0.003 0.0015
org-columns-new-overlay 216 0.003 1.38...e-005
org-columns-quit 1 0.002 0.002
org-columns-cleanup-item 54 0.002 3.70...e-005
org-columns-display-here-title 1 0.001 0.001
org-columns-compile-format 1 0.0 0.0
org-columns-compute-all 1 0.0 0.0
org-columns-number-to-string 1 0.0 0.0
org-columns-get-autowidth-alist 1 0.0 0.0
org-columns-add-ellipses 162 0.0 0.0
org-columns-compact-links 54 0.0 0.0
org-columns-get-format 1 0.0 0.0
org-columns-goto-top-level 1 0.0 0.0
elp-instrument-packages org
org-ctrl-c-ctrl-c 1 228.703 228.703
org-update-dblock 1 228.701 228.701
org-dblock-write:columnview 1 226.705 226.705
org-columns 1 216.804 216.804
org-goto-line 54 110.9 2.0537037037
org-table-align 1 8.276 8.276
org-columns-capture-view 1 1.603 1.603
org-entry-properties 54 0.2940000000 0.0054444444
org-get-tags-at 54 0.1210000000 0.0022407407
org-entry-get 58 0.1210000000 0.0020862068
org-entry-blocked-p 54 0.1190000000 0.0022037037
org-up-heading-safe 251 0.0940000000 0.0003745019
org-back-to-heading 870 0.0590000000 6.78...e-005
org-outline-level 449 0.0490000000 0.0001091314
org-columns-display-here 54 0.0460000000 0.0008518518
org-element--cache-record-change 81 0.0370000000 0.0004567901
org-get-property-block 110 0.0310000000 0.0002818181
org-element--cache-before-change 81 0.0290000000 0.0003580246
org-element--cache-sync 2 0.012 0.006
org-before-first-heading-p 56 0.0090000000 0.0001607142
org-columns-new-overlay 216 0.006 2.77...e-005
org-split-string 165 0.005 3.03...e-005
org-find-entry-with-id 1 0.004 0.004
org-prepare-dblock 1 0.004 0.004
org-get-limited-outline-regexp 169 0.004 2.36...e-005
org-columns-cleanup-item 54 0.004 7.40...e-005
org-do-emphasis-faces 3 0.003 0.001
org-at-heading-p 63 0.002 3.17...e-005
org-end-of-subtree 1 0.002 0.002
org-columns-quit 1 0.002 0.002
org-element-at-point 1 0.002 0.002
org-columns-remove-overlays 2 0.002 0.001
org-element-context 1 0.002 0.002
org-get-tags-string 54 0.002 3.70...e-005
org-fontify-meta-lines-and-blocks 3 0.001 0.0003333333
org-clock-update-mode-line 4 0.001 0.00025
org-beginning-of-dblock 1 0.001 0.001
org-get-category 54 0.001 1.85...e-005
org-overlay-display 216 0.001 4.62...e-006
org-entry-get-with-inheritance 2 0.001 0.0005
org-remove-uninherited-tags 161 0.001 6.21...e-006
org-element-paragraph-parser 1 0.001 0.001
org-remove-tabs 54 0.001 1.85...e-005
org-element--current-element 4 0.001 0.00025
org-minutes-to-clocksum-string 5 0.001 0.0002
org-fontify-meta-lines-and-blocks-1 3 0.001 0.0003333333
org-listtable-to-string 1 0.001 0.001
org-string-width 165 0.001 6.06...e-006
org-clock-get-clock-string 4 0.001 0.00025
org-columns-goto-top-level 1 0.001 0.001
org-add-hook 1 0.0 0.0
org-columns-display-here-title 1 0.0 0.0
org-activate-plain-links 3 0.0 0.0
org-element-type 1 0.0 0.0
org-activate-tags 3 0.0 0.0
org-babel-lob-get-info 1 0.0 0.0
org-fontify-drawers 3 0.0 0.0
org-babel-execute-safely-maybe 1 0.0 0.0
org-babel-execute-maybe 1 0.0 0.0
org-hours-to-clocksum-string 1 0.0 0.0
org-table-current-column 1 0.0 0.0
org-columns-compile-format 1 0.0 0.0
org-element-cache-put 4 0.0 0.0
org-not-nil 2 0.0 0.0
org-unfontify-region 3 0.0 0.0
org-remove-font-lock-display-properties 3 0.0 0.0
org-add-props 56 0.0 0.0
org-babel-hash-at-point 1 0.0 0.0
org-activate-dates 3 0.0 0.0
org-footnote-next-reference-or-definition 3 0.0 0.0
org-get-level-face 54 0.0 0.0
org-element-dynamic-block-parser 1 0.0 0.0
org-hide-wide-columns 3 0.0 0.0
org-activate-bracket-links 3 0.0 0.0
org-item-re 1 0.0 0.0
org-activate-target-links 3 0.0 0.0
org-remove-if 2 0.0 0.0
org-at-table-p 1 0.0 0.0
org-add-prop-inherited 323 0.0 0.0
org-columns-compute-all 1 0.0 0.0
org-update-property-plist 2 0.0 0.0
org-trim 98 0.0 0.0
org-columns-number-to-string 1 0.0 0.0
org-propertize 12 0.0 0.0
org-string-nw-p 3 0.0 0.0
org-activate-footnote-links 3 0.0 0.0
org-babel-where-is-src-block-head 1 0.0 0.0
org-activate-angle-links 3 0.0 0.0
org-font-lock-add-priority-faces 3 0.0 0.0
org-before-change-function 81 0.0 0.0
org-element-property 1 0.0 0.0
org-columns-get-autowidth-alist 1 0.0 0.0
org-raise-scripts 3 0.0 0.0
org-element--collect-affiliated-keywords 4 0.0 0.0
org-element-drawer-parser 1 0.0 0.0
org-fontify-macros 3 0.0 0.0
org-font-lock-hook 3 0.0 0.0
org-verify-version 1 0.0 0.0
org-set-local 5 0.0 0.0
org-element--cache-compare 91 0.0 0.0
org-do-latex-and-related 3 0.0 0.0
org-delete-all 161 0.0 0.0
org-resolve-clocks-if-idle 4 0.0 0.0
org-string-match-p 3 0.0 0.0
org-columns-add-ellipses 162 0.0 0.0
org-babel-execute-src-block-maybe 1 0.0 0.0
org-element--cache-mapc 2 0 0.0
org-clock-get-clocked-time 4 0.0 0.0
org-float-time 8 0.0 0.0
org-element-property-drawer-parser 1 0.0 0.0
org-babel-lob-execute-maybe 1 0.0 0.0
org-table-end 1 0.0 0.0
org-babel-get-inline-src-block-matches 1 0.0 0.0
org-activate-code 3 0.0 0.0
org-columns-compact-links 54 0.0 0.0
org-table-goto-column 1 0.0 0.0
org-element-cache-get 3 0.0 0.0
org-quote-vert 162 0.0 0.0
org-reduced-level 54 0.0 0.0
org-columns-get-format 1 0.0 0.0
org-table-begin 1 0.0 0.0
org-fontify-entities 3 0.0 0.0
org-font-lock-add-tag-faces 3 0.0 0.0
#+END_QUOTE
Same subtree standalone in org-mode file (28 KiB):
#+BEGIN_QUOTE
C-c C-c on same subtree in small file.
GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
org-ctrl-c-ctrl-c 1 0.109 0.109
org-update-dblock 1 0.109 0.109
org-columns 1 0.094 0.094
org-dblock-write:columnview 1 0.094 0.094
org-columns-add-ellipses 252 0.063 0.00025
org-columns-display-here 63 0.063 0.001
org-entry-properties 63 0.031 0.0004920634
org-entry-get 67 0.015 0.0002238805
org-entry-blocked-p 63 0.015 0.0002380952
org-get-property-block 128 0.015 0.0001171875
org-remove-flyspell-overlays-in 1 0.0 0.0
org-columns-goto-top-level 1 0.0 0.0
org-font-lock-add-tag-faces 8 0.0 0.0
org-fontify-entities 8 0.0 0.0
org-columns-cleanup-item 63 0.0 0.0
org-table-begin 1 0.0 0.0
org-columns-get-format 1 0.0 0.0
org-reduced-level 63 0.0 0.0
org-quote-vert 252 0.0 0.0
org-element-cache-get 3 0.0 0.0
org-table-goto-column 1 0.0 0.0
org-get-tags-string 63 0.0 0.0
org-columns-compact-links 63 0.0 0.0
org-activate-code 8 0.0 0.0
org-columns-capture-view 1 0.0 0.0
org-babel-get-inline-src-block-matches 1 0.0 0.0
org-element-context 1 0.0 0.0
org-string-width 256 0.0 0.0
org-element--cache-before-change 97 0.0 0.0
org-table-end 1 0.0 0.0
org-babel-lob-execute-maybe 1 0.0 0.0
org-element-property-drawer-parser 1 0.0 0.0
org-columns-new-overlay 315 0.0 0.0
org-babel-execute-src-block-maybe 1 0.0 0.0
org-listtable-to-string 1 0.0 0.0
org-string-match-p 8 0.0 0.0
org-delete-all 125 0.0 0.0
org-do-latex-and-related 8 0.0 0.0
org-element--cache-compare 20 0.0 0.0
org-fontify-meta-lines-and-blocks-1 8 0.0 0.0
org-verify-version 1 0.0 0.0
org-minutes-to-clocksum-string 1 0.0 0.0
org-columns-remove-overlays 2 0.0 0.0
org-font-lock-hook 8 0.0 0.0
org-element--current-element 4 0.0 0.0
org-fontify-macros 8 0.0 0.0
org-element-drawer-parser 1 0.0 0.0
org-element--collect-affiliated-keywords 4 0.0 0.0
org-raise-scripts 8 0.0 0.0
org-element-at-point 1 0.0 0.0
org-columns-get-autowidth-alist 1 0.0 0.0
org-element-property 1 0.0 0.0
org-before-change-function 97 0.0 0.0
org-font-lock-add-priority-faces 8 0.0 0.0
org-activate-angle-links 8 0.0 0.0
org-babel-where-is-src-block-head 1 0.0 0.0
org-element--cache-record-change 96 0.0 0.0
org-split-string 129 0.0 0.0
org-activate-footnote-links 8 0.0 0.0
org-back-to-heading 630 0.0 0.0
org-before-first-heading-p 65 0.0 0.0
org-get-limited-outline-regexp 200 0.0 0.0
org-remove-tabs 63 0.0 0.0
org-string-nw-p 8 0.0 0.0
org-element--cache-sync 2 0.0 0.0
org-rear-nonsticky-at 1 0.0 0.0
org-columns-number-to-string 1 0.0 0.0
org-trim 162 0.0 0.0
org-update-property-plist 2 0.0 0.0
org-columns-compute-all 1 0.0 0.0
org-element-paragraph-parser 1 0.0 0.0
org-add-prop-inherited 62 0.0 0.0
org-at-table-p 1 0.0 0.0
org-remove-if 2 0.0 0.0
org-activate-target-links 8 0.0 0.0
org-item-re 1 0.0 0.0
org-columns-quit 1 0.0 0.0
org-activate-bracket-links 8 0.0 0.0
org-end-of-subtree 1 0.0 0.0
org-up-heading-safe 165 0.0 0.0
org-hide-wide-columns 8 0.0 0.0
org-element-dynamic-block-parser 1 0.0 0.0
org-prepare-dblock 1 0.0 0.0
org-get-level-face 63 0.0 0.0
org-footnote-next-reference-or-definition 8 0.0 0.0
org-activate-dates 8 0.0 0.0
org-remove-uninherited-tags 125 0.0 0.0
org-babel-hash-at-point 1 0.0 0.0
org-add-props 65 0.0 0.0
org-remove-font-lock-display-properties 8 0.0 0.0
org-unfontify-region 8 0.0 0.0
org-at-heading-p 73 0.0 0.0
org-not-nil 2 0.0 0.0
org-get-tags-at 63 0.0 0.0
org-element-cache-put 4 0.0 0.0
org-find-entry-with-id 1 0.0 0.0
org-columns-compile-format 1 0.0 0.0
org-table-current-column 1 0.0 0.0
org-entry-get-with-inheritance 2 0.0 0.0
org-hours-to-clocksum-string 1 0.0 0.0
org-babel-execute-maybe 1 0.0 0.0
org-overlay-display 315 0.0 0.0
org-babel-execute-safely-maybe 1 0.0 0.0
org-fontify-drawers 8 0.0 0.0
org-get-category 63 0.0 0.0
org-beginning-of-dblock 1 0.0 0.0
org-babel-lob-get-info 1 0.0 0.0
org-outline-level 268 0.0 0.0
org-activate-tags 8 0.0 0.0
org-element-type 1 0.0 0.0
org-activate-plain-links 8 0.0 0.0
org-do-emphasis-faces 8 0.0 0.0
org-fontify-meta-lines-and-blocks 8 0.0 0.0
org-table-align 1 0.0 0.0
org-columns-display-here-title 1 0.0 0.0
org-add-hook 1 0.0 0.0
#+END_QUOTE
#+BEGIN_QUOTE
C-c C-c on same subtree in small file.
GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-02-17 on ODIEONE
org-ctrl-c-ctrl-c 1 0.858 0.858
org-update-dblock 1 0.733 0.733
org-entry-properties 63 0.139 0.0022063492
org-babel-execute-safely-maybe 1 0.125 0.125
org-babel-execute-maybe 1 0.125 0.125
org-babel-execute-src-block-maybe 1 0.125 0.125
org-babel-get-inline-src-block-matches 1 0.125 0.125
org-get-tags-at 63 0.077 0.0012222222
org-get-property-block 128 0.047 0.0003671875
org-element--cache-before-change 96 0.047 0.0004895833
org-entry-blocked-p 63 0.047 0.0007460317
org-entry-get 67 0.047 0.0007014925
org-element--cache-record-change 96 0.046 0.0004791666
org-remove-uninherited-tags 125 0.031 0.000248
org-before-first-heading-p 65 0.016 0.0002461538
org-back-to-heading 630 0.016 2.53...e-005
org-split-string 129 0.016 0.0001240310
org-up-heading-safe 165 0.015 9.09...e-005
org-add-hook 1 0.0 0.0
org-refresh-category-properties 1 0.0 0.0
org-fontify-meta-lines-and-blocks 8 0.0 0.0
org-do-emphasis-faces 8 0.0 0.0
org-activate-plain-links 8 0.0 0.0
org-element-type 1 0.0 0.0
org-activate-tags 8 0.0 0.0
org-outline-level 268 0.0 0.0
org-babel-lob-get-info 1 0.0 0.0
org-beginning-of-dblock 1 0.0 0.0
org-get-category 63 0.0 0.0
org-fontify-drawers 8 0.0 0.0
org-overlay-display 315 0.0 0.0
org-entry-get-with-inheritance 2 0.0 0.0
org-element-cache-put 2 0.0 0.0
org-find-entry-with-id 1 0.0 0.0
org-not-nil 2 0.0 0.0
org-at-heading-p 68 0.0 0.0
org-unfontify-region 8 0.0 0.0
org-remove-font-lock-display-properties 8 0.0 0.0
org-add-props 65 0.0 0.0
org-find-if 58 0.0 0.0
org-babel-hash-at-point 1 0.0 0.0
org-activate-dates 8 0.0 0.0
org-footnote-next-reference-or-definition 8 0.0 0.0
org-get-level-face 63 0.0 0.0
org-prepare-dblock 1 0.0 0.0
org-element-dynamic-block-parser 1 0.0 0.0
org-hide-wide-columns 8 0.0 0.0
org-end-of-subtree 1 0.0 0.0
org-activate-bracket-links 8 0.0 0.0
org-item-re 1 0.0 0.0
org-activate-target-links 8 0.0 0.0
org-remove-if 2 0.0 0.0
org-at-table-p 1 0.0 0.0
org-add-prop-inherited 62 0.0 0.0
org-element-paragraph-parser 1 0.0 0.0
org-update-property-plist 2 0.0 0.0
org-trim 162 0.0 0.0
org-element--cache-sync 2 0.0 0.0
org-rear-nonsticky-at 1 0.0 0.0
org-string-nw-p 8 0.0 0.0
org-remove-tabs 63 0.0 0.0
org-get-limited-outline-regexp 197 0.0 0.0
org-activate-footnote-links 8 0.0 0.0
org-babel-where-is-src-block-head 1 0.0 0.0
org-activate-angle-links 8 0.0 0.0
org-font-lock-add-priority-faces 8 0.0 0.0
org-before-change-function 96 0.0 0.0
org-defkey 58 0.0 0.0
org-element-property 1 0.0 0.0
org-element-at-point 1 0.0 0.0
org-raise-scripts 8 0.0 0.0
org-element--collect-affiliated-keywords 2 0.0 0.0
org-fontify-macros 8 0.0 0.0
org-element--current-element 2 0.0 0.0
org-font-lock-hook 8 0.0 0.0
org-fontify-meta-lines-and-blocks-1 8 0.0 0.0
org-element--cache-compare 287 0.0 0.0
org-do-latex-and-related 8 0.0 0.0
org-string-match-p 8 0.0 0.0
org-element--cache-mapc 1 0.0 0.0
org-babel-lob-execute-maybe 1 0.0 0.0
org-string-width 256 0.0 0.0
org-element-context 1 0.0 0.0
org-activate-code 8 0.0 0.0
org-get-tags-string 63 0.0 0.0
org-key 58 0.0 0.0
org-element-cache-get 3 0.0 0.0
org-quote-vert 252 0.0 0.0
org-reduced-level 63 0.0 0.0
org-fontify-entities 8 0.0 0.0
org-font-lock-add-tag-faces 8 0.0 0.0
org-remove-flyspell-overlays-in 1 0.0 0.0
#+END_QUOTE
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-21 15:51 ` Stefan-W. Hahn
@ 2014-02-21 17:50 ` Stefan Monnier
2014-02-22 8:38 ` Stefan-W. Hahn
[not found] ` <20140222083926.GC27381@pille.home>
0 siblings, 2 replies; 24+ messages in thread
From: Stefan Monnier @ 2014-02-21 17:50 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
>> If not, perhaps you could show a file with which you see this.
> No, sorry.
Could you maybe "neuter" the file? E.g pass it through
sed 's/[[:alnum:]]/a/'
so that it doesn't contain any important information any more (while
still triggering the problem)?
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-21 17:50 ` Stefan Monnier
@ 2014-02-22 8:38 ` Stefan-W. Hahn
[not found] ` <20140222083926.GC27381@pille.home>
1 sibling, 0 replies; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-22 8:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16830
Mail von Stefan Monnier, Fri, 21 Feb 2014 at 12:50:10 -0500:
Good morning,
> >> If not, perhaps you could show a file with which you see this.
> > No, sorry.
>
> Could you maybe "neuter" the file? E.g pass it through
>
> sed 's/[[:alnum:]]/a/'
>
> so that it doesn't contain any important information any more (while
> still triggering the problem)?
I have 'neutered' the file as you suggested and rewritten the item
in which the or-structure must be preserved.
If you search for #### you will find the item, which shows the problem.
If you then type C-c C-c on the #+BEGIN line you will get it.
I observed that it is not as slow as in the original file. Perhaps this
has to do with to fontifying, because org-mode now has much less to fontify.
It also makes no difference if the items after this item are inside the
file.
But anyway it is compared to an older emacs where it takes less then a
second to update the table.
Hopes this will help.
(I send the file just to you two.)
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
[not found] ` <20140222083926.GC27381@pille.home>
@ 2014-02-22 9:18 ` Eli Zaretskii
2014-02-22 11:08 ` Stefan-W. Hahn
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-22 9:18 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
> Date: Sat, 22 Feb 2014 09:39:27 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: Eli Zaretskii <eliz@gnu.org>
>
> If you search for #### you will find the item, which shows the problem.
> If you then type C-c C-c on the #+BEGIN line you will get it.
>
> I observed that it is not as slow as in the original file. Perhaps this
> has to do with to fontifying, because org-mode now has much less to fontify.
> It also makes no difference if the items after this item are inside the
> file.
>
> But anyway it is compared to an older emacs where it takes less then a
> second to update the table.
OK, I can confirm the slow-down. The profile points to forward-line,
so I disabled cache-long-scans, and -- lo and behold -- the slowdown
went away. So this should be the workaround for the time being.
It looks like the overhead of caching newlines, which is supposed to
be small, is somehow very large in this case.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 9:18 ` Eli Zaretskii
@ 2014-02-22 11:08 ` Stefan-W. Hahn
2014-02-22 11:29 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-22 11:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
Mail von Eli Zaretskii, Sat, 22 Feb 2014 at 11:18:08 +0200:
Hello,
> > But anyway it is compared to an older emacs where it takes less then a
> > second to update the table.
>
> OK, I can confirm the slow-down. The profile points to forward-line,
> so I disabled cache-long-scans, and -- lo and behold -- the slowdown
> went away. So this should be the workaround for the time being.
Sounds good. Is it right that I can set this variable globally only by
installing a function setting it in find-file-hook?
I tested it that way with my original file.
(elp-instrument-package org; elp-result for org-ctrl-c-ctrl-c)
emacs 24.3.50.1 2.083 sec (cache-long-scans nil, set by file-find-hook)
emacs 24.3.1 0.758 sec (cache-long-line-scan nil; as it was)
So it is better, but not so good as in the old emacs.
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 11:08 ` Stefan-W. Hahn
@ 2014-02-22 11:29 ` Eli Zaretskii
2014-02-22 11:36 ` Eli Zaretskii
2014-02-22 12:27 ` Stefan-W. Hahn
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-22 11:29 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
> Date: Sat, 22 Feb 2014 12:08:58 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 16830@debbugs.gnu.org
>
> > OK, I can confirm the slow-down. The profile points to forward-line,
> > so I disabled cache-long-scans, and -- lo and behold -- the slowdown
> > went away. So this should be the workaround for the time being.
>
> Sounds good. Is it right that I can set this variable globally only by
> installing a function setting it in find-file-hook?
Doesn't sound like a good idea to me: that would disable the caching
for much more than this Org file, or even just Org files, right? I
would suggest to selectively disable caching only for those files that
are actually affected in perceptible way, because the caching in
general does speed up things.
> I tested it that way with my original file.
> (elp-instrument-package org; elp-result for org-ctrl-c-ctrl-c)
>
> emacs 24.3.50.1 2.083 sec (cache-long-scans nil, set by file-find-hook)
> emacs 24.3.1 0.758 sec (cache-long-line-scan nil; as it was)
>
> So it is better, but not so good as in the old emacs.
I see no difference in the code that could justify this, and on my
system "C-c C-c" in both versions completes in the same time after
disabling the caching, certainly much faster than 2 sec. So I don't
see how such a 2.5 factor could be explained, except perhaps by some
additional local customizations on your system (I tested in "emacs -Q").
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 11:29 ` Eli Zaretskii
@ 2014-02-22 11:36 ` Eli Zaretskii
2014-02-22 12:33 ` Stefan-W. Hahn
2014-02-22 12:27 ` Stefan-W. Hahn
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-22 11:36 UTC (permalink / raw)
To: stefan.hahn; +Cc: 16830
> Date: Sat, 22 Feb 2014 13:29:48 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16830@debbugs.gnu.org
>
> > emacs 24.3.50.1 2.083 sec (cache-long-scans nil, set by file-find-hook)
> > emacs 24.3.1 0.758 sec (cache-long-line-scan nil; as it was)
> >
> > So it is better, but not so good as in the old emacs.
>
> I see no difference in the code that could justify this, and on my
> system "C-c C-c" in both versions completes in the same time after
> disabling the caching, certainly much faster than 2 sec. So I don't
> see how such a 2.5 factor could be explained, except perhaps by some
> additional local customizations on your system (I tested in "emacs -Q").
Actually, I _can_ think of one possible reason for this difference:
compiler optimizations. If the 24.3.50.1 binary was compiled without
optimizations, it can definitely be about 2 times slower than an
optimized build of 24.3.1. What is the value of system-configuration
and system-configuration-options in both builds?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 11:29 ` Eli Zaretskii
2014-02-22 11:36 ` Eli Zaretskii
@ 2014-02-22 12:27 ` Stefan-W. Hahn
2014-03-10 18:58 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-22 12:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
Mail von Eli Zaretskii, Sat, 22 Feb 2014 at 13:29:48 +0200:
Hello,
> Doesn't sound like a good idea to me: that would disable the caching
> for much more than this Org file, or even just Org files, right? I
> would suggest to selectively disable caching only for those files that
Ok.
> > I tested it that way with my original file.
> > (elp-instrument-package org; elp-result for org-ctrl-c-ctrl-c)
> >
> > emacs 24.3.50.1 2.083 sec (cache-long-scans nil, set by file-find-hook)
> > emacs 24.3.1 0.758 sec (cache-long-line-scan nil; as it was)
> >
> > So it is better, but not so good as in the old emacs.
>
> I see no difference in the code that could justify this, and on my
> system "C-c C-c" in both versions completes in the same time after
> disabling the caching, certainly much faster than 2 sec. So I don't
> see how such a 2.5 factor could be explained, except perhaps by some
> additional local customizations on your system (I tested in "emacs -Q").
Argh... you're right, here the measurement with "emacs -Q":
(elp-instrument-package org; elp-result for org-ctrl-c-ctrl-c)
my original org-mode file:
emacs 24.3.50.1 2.065 sec (cache-long-scans nil, set local)
emacs 24.3.1 0.722 sec (cache-long-line-scan nil; as it was)
test-neuter.org:
emacs 24.3.50.1 0.925 sec (cache-long-scans nil, set local)
emacs 24.3.1 0.381 sec (cache-long-line-scan nil; as it was)
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 11:36 ` Eli Zaretskii
@ 2014-02-22 12:33 ` Stefan-W. Hahn
2014-02-22 12:55 ` Juanma Barranquero
2014-02-22 13:05 ` Eli Zaretskii
0 siblings, 2 replies; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-22 12:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
Mail von Eli Zaretskii, Sat, 22 Feb 2014 at 13:36:17 +0200:
Hello,
> Actually, I _can_ think of one possible reason for this difference:
> compiler optimizations. If the 24.3.50.1 binary was compiled without
> optimizations, it can definitely be about 2 times slower than an
> optimized build of 24.3.1. What is the value of system-configuration
> and system-configuration-options in both builds?
How can I retrieve them?
Both are precompiled version I downloaded; the 24.3.50.1 from dropbox:
https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
I'm not sure where I got the older one.
(I wasn't able to compile it myself on windows; I tried it, but I wasn't
able to find all prerequisites. This is really easier on linux.)
With kind reagrds,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 12:33 ` Stefan-W. Hahn
@ 2014-02-22 12:55 ` Juanma Barranquero
2014-02-22 15:06 ` Stefan-W. Hahn
2014-02-22 13:05 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Juanma Barranquero @ 2014-02-22 12:55 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Feb 22, 2014 1:34 PM, "Stefan-W. Hahn" <stefan.hahn@s-hahn.de> wrote:
> the 24.3.50.1 from dropbox:
> https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
Definitely a non-optimized, checking=yes,glyphs build.
Just out of curiosity, where did you get that Dropbox link from?
J
[-- Attachment #2: Type: text/html, Size: 520 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 12:33 ` Stefan-W. Hahn
2014-02-22 12:55 ` Juanma Barranquero
@ 2014-02-22 13:05 ` Eli Zaretskii
2014-02-21 7:43 ` Stefan-W. Hahn
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-22 13:05 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
> Date: Sat, 22 Feb 2014 13:33:14 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 16830@debbugs.gnu.org
>
> > Actually, I _can_ think of one possible reason for this difference:
> > compiler optimizations. If the 24.3.50.1 binary was compiled without
> > optimizations, it can definitely be about 2 times slower than an
> > optimized build of 24.3.1. What is the value of system-configuration
> > and system-configuration-options in both builds?
>
> How can I retrieve them?
You need to evaluate them inside Emacs:
M-: system-configuration RET
M-: system-configuration-options RET
> Both are precompiled version I downloaded; the 24.3.50.1 from dropbox:
> https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
I'm quite sure the release binary is optimized, while the snapshot one
is not.
> (I wasn't able to compile it myself on windows; I tried it, but I wasn't
> able to find all prerequisites. This is really easier on linux.)
Latest versions compile like on GNU/Linux, you just need to create a
suitable environment first, using the advice in nt/INSTALL.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 12:55 ` Juanma Barranquero
@ 2014-02-22 15:06 ` Stefan-W. Hahn
0 siblings, 0 replies; 24+ messages in thread
From: Stefan-W. Hahn @ 2014-02-22 15:06 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16830
Mail von Juanma Barranquero, Sat, 22 Feb 2014 at 13:55:53 +0100:
Hello,
> > the 24.3.50.1 from dropbox:
> > https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
>
> Definitely a non-optimized, checking=yes,glyphs build.
>
> Just out of curiosity, where did you get that Dropbox link from?
From Eli.
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-21 7:43 ` Stefan-W. Hahn
@ 2014-02-23 18:04 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-02-23 18:04 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: 16830
> Date: Fri, 21 Feb 2014 08:43:09 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 16830@debbugs.gnu.org
[This doesn't really belong to this bug report.]
> I tried to install MinGW/MSYS as described in nt/INSTALL. I started msys.bat
> and configured with "./configure --prefix=/d/bin/emacs-mingw" .It configured well
No, it didn't configure well. One can see the signs of trouble
already here:
> Configured for `i686-pc-mingw32'.
>
> Where should the build process find the source code? .
> What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2 -gdwarf-2
> Should Emacs use the GNU version of malloc? yes
> Should Emacs use a relocating allocator for buffers? yes
> Should Emacs use mmap(2) for buffer allocation? no
> What window system should Emacs use? w32
> What toolkit should Emacs use? none
> Where do we find X Windows header files? NONE
> Where do we find X Windows libraries? NONE
> Does Emacs use -lXaw3d? no
> Does Emacs use -lXpm? no
> Does Emacs use -ljpeg? no
> Does Emacs use -ltiff? no
> Does Emacs use a gif library? no
> Does Emacs use -lpng? no
> Does Emacs use -lrsvg-2? yes
> Does Emacs use imagemagick? yes
^^^
> Does Emacs support sound? yes
> Does Emacs use -lgpm? no
> Does Emacs use -ldbus? yes
^^^
> Does Emacs use -lgconf? no
> Does Emacs use GSettings? no
> Does Emacs use a file notification library? yes -lgio (gfile)
^^^^^^^^^^^^^^^^^
> Does Emacs use access control lists? yes
> Does Emacs use -lselinux? no
> Does Emacs use -lgnutls? yes
> Does Emacs use -lxml2? yes
> Does Emacs use -lfreetype? no
> Does Emacs use -lm17n-flt? no
> Does Emacs use -lotf? no
> Does Emacs use -lxft? no
> Does Emacs directly use zlib? no
> Does Emacs use toolkit scroll bars? yes
> gcc -std=gnu99 -mtune=pentium4 -I. -I. -mtune=pentium4 -DUSE_CRT_DLL=1 -I /d/home/hs/src/emacs.git/nt/inc -g3 -O2 -gdwarf-2
> ./addsection.c -o addsection.exe
> In file included from /usr/include/sys/fcntl.h:164,
> from /usr/include/fcntl.h:14,
> from ./addsection.c:26:
> /d/home/hs/src/emacs.git/nt/inc/sys/stat.h:90: error: parse error before "st_ino"
Looks like you don't have MinGW Windows headers, at least some of
them. Did you install the w32 API headers?
And here's the evidence that you probably didn't:
> checking windows.h usability... no
> checking windows.h presence... yes
> configure: WARNING: windows.h: present but cannot be compiled
> configure: WARNING: windows.h: check for missing prerequisite headers?
> configure: WARNING: windows.h: see the Autoconf documentation
> configure: WARNING: windows.h: section "Present But Cannot Be Compiled"
> configure: WARNING: windows.h: proceeding with the compiler's result
> checking for windows.h... no
Likewise this:
> checking netinet/in.h usability... no
> checking netinet/in.h presence... yes
> configure: WARNING: netinet/in.h: present but cannot be compiled
> configure: WARNING: netinet/in.h: check for missing prerequisite headers?
> configure: WARNING: netinet/in.h: see the Autoconf documentation
> configure: WARNING: netinet/in.h: section "Present But Cannot Be Compiled"
> configure: WARNING: netinet/in.h: proceeding with the compiler's result
> checking for netinet/in.h... no
Look in config.log, it should probably tell you right away what is
wrong with your MinGW/MSYS installation.
Also, this:
> checking for gnutls >= 3.0.0... yes CFLAGS='-I/usr/include/p11-kit-1 ' LIBS='-L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz '
looks wrong: the file names without drive letters seem to suggest that
you installed the MinGW headers into the same tree as MSYS? I don't
recommend that.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-02-22 12:27 ` Stefan-W. Hahn
@ 2014-03-10 18:58 ` Eli Zaretskii
2014-03-11 8:08 ` martin rudalics
2014-03-17 15:05 ` bug#16830: " Dmitry Antipov
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-03-10 18:58 UTC (permalink / raw)
To: Stefan-W. Hahn, Stefan Monnier; +Cc: 16830
> Date: Sat, 22 Feb 2014 13:27:47 +0100
> From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
> Cc: 16830@debbugs.gnu.org
>
> my original org-mode file:
> emacs 24.3.50.1 2.065 sec (cache-long-scans nil, set local)
> emacs 24.3.1 0.722 sec (cache-long-line-scan nil; as it was)
>
> test-neuter.org:
> emacs 24.3.50.1 0.925 sec (cache-long-scans nil, set local)
> emacs 24.3.1 0.381 sec (cache-long-line-scan nil; as it was)
So I think it's a very Good Thing that we have this bug report,
because looking into this issue produced a surprising (for me)
discovery: turning off the newline cache makes forward-line
significantly (5 to 20 times, depending on the file) faster than when
the cache is turned on, for files with relatively short lines.
It looks like the GCC implementation of memchr, used by the "dumb
loop" in find_newline, is so efficient that it easily outperforms the
"smart loop" which uses the cache, unless lines are very long, like at
least 400 characters, at which point the code performs with and
without the cache at the same speed.
This striking difference in speed goes mostly unnoticed, because
typically Emacs seldom if ever calls forward-line too much (see below
for how much should "too much" for this to become visible). However,
typing "C-c C-c" in the OP's Org file does just that -- it causes
forward-line be invoked a huge number of times, because it walks the
(29K line) Org file one line at a time with this function:
(defsubst org-goto-line (N)
(save-restriction
(widen)
(goto-char (point-min))
(forward-line (1- N))))
IOW, to move from line N to line N+1, this goes back to the beginning,
and then traverses all the N lines again, plus one more line. Not a
very efficient way, to put it mildly. So I suggest that Org
developers look into making this use case more efficient, no matter
whether the changes suggested below are or aren't installed.
Inspired by the above function, I profiled find_newline, which is the
workhorse of forward-line, using xdisp.c as the test file and this
silly program:
(let ((n 1))
(while (not (eobp))
(goto-char 1)
(forward-line n)
(setq n (1+ n))))
Running this program on xdisp.c calls find_newline 30K times and
exercises its inner loop, which looks for the next newline, 450
million times. On my machine and in an optimized build, this takes
about 1 min 14 sec with the cache turned on, and only 12 sec with it
turned off, a factor of 6.
By careful optimization of find_newline, I have succeeded to slash the
time of the above loop by a factor of 2, see the proposed patch below.
The "C-c C-c" command in the OP's Org file runs 3 times faster with
those changes, and takes only 2 sec instead of 6.5. This still leaves
the no-cache operation faster by a factor of about 3, though, in both
these test cases.
Again, this is for files whose average line length is 30 to 50
characters. For files whose lines are at least 10 times longer,
the times with and without cache become almost identical, and for
longer lines the cache starts to win.
It would be nice to be able to turn the cache on and off dynamically,
depending on the actual line length of the buffer. I tried to
implement this, but my naive implementation didn't work well, because
sampling of the lines tends to be extremely un-representative. If
someone can come up with a smarter implementation, please show it.
Until we can dynamically estimate the line length and turn the cache
on only for long lines, I suggest to leave the default ON, and install
the patches below. My reasoning is that in most situations the
slow-down is negligible, while for very long lines the speedup can be
significant.
For the record, here are the measurements I made, before and after the
changes, with 2 test cases: xdisp.c scanning with the above program,
and the "neutered" Org file posted by Stefan-W. Hahn:
Test Code Optimized? Cache ON Cache OFF
---------------------------------------------------
Org old NO 11.3s 0.8s
Org new NO 3.6s 0.8s
Org old YES 6.5s 0.3s
Org new YES 2.0s 0.25s
xdisp.c old NO 2m11.8s 14.7s
xdisp.c new NO 1m03.3s 14.8s
xdisp.c old YES 1m14.4s 12.0s
xdisp.c new YES 32.5s 11.8s
And here are the patches I propose. (Note that I only handled the
forward scan; the backward scan is used much less, so I left it alone,
but if someone thinks the asymmetry might be confusing, I can do the
same surgery with backward scan.)
Any objections to committing this?
--- src/search.c.~2~ 2014-01-02 07:07:04.000000000 +0200
+++ src/search.c 2014-03-10 19:40:08.607562800 +0200
@@ -715,18 +715,61 @@ find_newline (ptrdiff_t start, ptrdiff_t
examine. */
ptrdiff_t tem, ceiling_byte = end_byte - 1;
- /* If we're looking for a newline, consult the newline cache
- to see where we can avoid some scanning. */
+ /* If we're using the newline cache, consult it to see whether
+ we can avoid some scanning. */
if (newline_cache)
{
ptrdiff_t next_change;
+ int result = 1;
+
immediate_quit = 0;
- while (region_cache_forward
- (cache_buffer, newline_cache, start, &next_change))
- start = next_change;
- immediate_quit = allow_quit;
+ while (start < end && result)
+ {
+ ptrdiff_t lim1;
- start_byte = CHAR_TO_BYTE (start);
+ result = region_cache_forward (cache_buffer, newline_cache,
+ start, &next_change);
+ if (result)
+ {
+ start = next_change;
+ lim1 = next_change = end;
+ }
+ else
+ lim1 = min (next_change, end);
+
+ /* The cache returned zero for this region; see if
+ this is because the region is known and includes
+ only newlines. While at that, count any newlines
+ we bump into, and exit if we found enough off them. */
+ start_byte = CHAR_TO_BYTE (start);
+ while (start < lim1
+ && FETCH_BYTE (start_byte) == '\n')
+ {
+ start_byte++;
+ start++;
+ if (--count == 0)
+ {
+ if (bytepos)
+ *bytepos = start_byte;
+ return start;
+ }
+ }
+ /* If we found a non-newline character before hitting
+ position where the cache will again return non-zero
+ (i.e. no newlines beyond that position), it means
+ this region is not yet known to the cache, and we
+ must resort to the "dumb loop" method. */
+ if (start < next_change && !result)
+ break;
+ result = 1;
+ }
+ if (start >= end)
+ {
+ start = end;
+ start_byte = end_byte;
+ break;
+ }
+ immediate_quit = allow_quit;
/* START should never be after END. */
if (start_byte > ceiling_byte)
@@ -762,9 +805,9 @@ find_newline (ptrdiff_t start, ptrdiff_t
unsigned char *nl = memchr (lim_addr + cursor, '\n', - cursor);
next = nl ? nl - lim_addr : 0;
- /* If we're looking for newlines, cache the fact that
- this line's region is free of them. */
- if (newline_cache)
+ /* If we're using the newline cache, cache the fact that
+ the region we just traversed is free of newlines. */
+ if (newline_cache && cursor != next)
{
know_region_cache (cache_buffer, newline_cache,
BYTE_TO_CHAR (lim_byte + cursor),
@@ -840,7 +883,7 @@ find_newline (ptrdiff_t start, ptrdiff_t
/* If we're looking for newlines, cache the fact that
this line's region is free of them. */
- if (newline_cache)
+ if (newline_cache && cursor != prev + 1)
{
know_region_cache (cache_buffer, newline_cache,
BYTE_TO_CHAR (ceiling_byte + prev + 1),
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-10 18:58 ` Eli Zaretskii
@ 2014-03-11 8:08 ` martin rudalics
2014-03-11 17:03 ` Eli Zaretskii
2014-03-12 14:12 ` Stefan Monnier
2014-03-17 15:05 ` bug#16830: " Dmitry Antipov
1 sibling, 2 replies; 24+ messages in thread
From: martin rudalics @ 2014-03-11 8:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830, Stefan-W. Hahn
> Until we can dynamically estimate the line length and turn the cache
> on only for long lines, I suggest to leave the default ON, and install
> the patches below. My reasoning is that in most situations the
> slow-down is negligible, while for very long lines the speedup can be
> significant.
In general I inspect long lines only in bug reports. Is that sufficient
reason to not follow the advice
There is no reason to set this to nil except for debugging purposes.
after your patch is applied?
> And here are the patches I propose. (Note that I only handled the
> forward scan; the backward scan is used much less, so I left it alone,
> but if someone thinks the asymmetry might be confusing, I can do the
> same surgery with backward scan.)
Thanks for the work. If it's not difficult, I think the backward scan
should be fixed too. And I strongly favor to install this for 24.4.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-11 8:08 ` martin rudalics
@ 2014-03-11 17:03 ` Eli Zaretskii
2014-03-12 14:12 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-03-11 17:03 UTC (permalink / raw)
To: martin rudalics; +Cc: 16830, stefan.hahn
> Date: Tue, 11 Mar 2014 09:08:55 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>,
> Stefan Monnier <monnier@iro.umontreal.ca>,
> 16830@debbugs.gnu.org
>
> > Until we can dynamically estimate the line length and turn the cache
> > on only for long lines, I suggest to leave the default ON, and install
> > the patches below. My reasoning is that in most situations the
> > slow-down is negligible, while for very long lines the speedup can be
> > significant.
>
> In general I inspect long lines only in bug reports. Is that sufficient
> reason to not follow the advice
>
> There is no reason to set this to nil except for debugging purposes.
>
> after your patch is applied?
Actually, I suggest to only change the default if you ever see a
tangible difference with and without the cache.
If you review the timings I posted, you will realize that a single
call to find_newline takes a fraction of a microsecond on a reasonably
modern machine, so unless you use code that calls forward-line with a
very large argument, like hundreds of thousands, you will never see
the difference.
Also, turning off cache-long-scans disables not only the newline
cache, but also 2 other caches, at least one of which (the bidi
paragraph start cache) might be important for redisplay speed, and
doesn't suffer from the slowdown I discovered with the newline cache,
because the way we use that cache is very different.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-11 8:08 ` martin rudalics
2014-03-11 17:03 ` Eli Zaretskii
@ 2014-03-12 14:12 ` Stefan Monnier
2014-03-16 16:32 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2014-03-12 14:12 UTC (permalink / raw)
To: martin rudalics; +Cc: Stefan-W. Hahn, 16830
> Thanks for the work. If it's not difficult, I think the backward scan
> should be fixed too. And I strongly favor to install this for 24.4.
What he said,
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-12 14:12 ` Stefan Monnier
@ 2014-03-16 16:32 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-03-16 16:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: stefan.hahn, 16830
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>, 16830@debbugs.gnu.org
> Date: Wed, 12 Mar 2014 10:12:49 -0400
>
> > Thanks for the work. If it's not difficult, I think the backward scan
> > should be fixed too. And I strongly favor to install this for 24.4.
>
> What he said,
Done as trunk revision 116775.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: Re: bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-10 18:58 ` Eli Zaretskii
2014-03-11 8:08 ` martin rudalics
@ 2014-03-17 15:05 ` Dmitry Antipov
2014-03-17 16:39 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Dmitry Antipov @ 2014-03-17 15:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16830
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On 03/10/2014 10:58 PM, Eli Zaretskii wrote:
> It would be nice to be able to turn the cache on and off dynamically,
> depending on the actual line length of the buffer. I tried to
> implement this, but my naive implementation didn't work well, because
> sampling of the lines tends to be extremely un-representative. If
> someone can come up with a smarter implementation, please show it.
What if we just maintain the '\n' counter per each buffer text?
With that, finding an average line length is straightforward,
and the very basic implementation looks fairly simple; this
should be helpful in maintaining newline_cache as well.
Dmitry
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nl.patch --]
[-- Type: text/x-patch; name="nl.patch", Size: 4917 bytes --]
=== modified file 'src/buffer.c'
--- src/buffer.c 2014-03-15 11:16:12 +0000
+++ src/buffer.c 2014-03-17 14:42:01 +0000
@@ -573,6 +573,7 @@
BUF_END_UNCHANGED (b) = 0;
BUF_BEG_UNCHANGED (b) = 0;
*(BUF_GPT_ADDR (b)) = *(BUF_Z_ADDR (b)) = 0; /* Put an anchor '\0'. */
+ BUF_NL (b) = 0;
b->text->inhibit_shrinking = false;
b->text->redisplay = false;
=== modified file 'src/buffer.h'
--- src/buffer.h 2014-01-01 07:43:34 +0000
+++ src/buffer.h 2014-03-17 14:42:01 +0000
@@ -91,6 +91,9 @@
/* Modification count as of last visit or save. */
#define SAVE_MODIFF (current_buffer->text->save_modiff)
+/* How many '\n' in the buffer. */
+#define NL (current_buffer->text->nl)
+
/* BUFFER_CEILING_OF (resp. BUFFER_FLOOR_OF), when applied to n, return
the max (resp. min) p such that
@@ -183,6 +186,9 @@
/* FIXME: should we move this into ->text->auto_save_modiff? */
#define BUF_AUTOSAVE_MODIFF(buf) ((buf)->auto_save_modified)
+/* How many '\n' in the buffer. */
+#define BUF_NL(buf) ((buf)->text->nl)
+
/* Compaction count. */
#define BUF_COMPACT(buf) ((buf)->text->compact)
@@ -463,6 +469,9 @@
/* Properties of this buffer's text. */
INTERVAL intervals;
+ /* How many '\n' in this buffer's text. */
+ ptrdiff_t nl;
+
/* The markers that refer to this buffer.
This is actually a single marker ---
successive elements in its marker `chain'
=== modified file 'src/insdel.c'
--- src/insdel.c 2014-01-01 17:44:48 +0000
+++ src/insdel.c 2014-03-17 14:55:57 +0000
@@ -560,7 +560,20 @@
return to_addr - initial_to_addr;
}
}
-\f
+
+/* Count '\n' in [PTR..PTR + NBYTES). */
+
+static ptrdiff_t
+count_newlines (const char *ptr, ptrdiff_t nbytes)
+{
+ const char *p = ptr;
+ ptrdiff_t count = 0, restbytes = nbytes;
+
+ while (restbytes > 0 && (p = memchr (p, '\n', restbytes)))
+ p++, count++, restbytes = nbytes - (p - ptr);
+ return count;
+}
+
/* Insert a string of specified length before point.
This function judges multibyteness based on
enable_multibyte_characters in the current buffer;
@@ -814,6 +827,9 @@
MODIFF++;
CHARS_MODIFF = MODIFF;
+ /* Count newlines in new text. */
+ NL += count_newlines (string, nbytes);
+
memcpy (GPT_ADDR, string, nbytes);
GAP_SIZE -= nbytes;
@@ -924,6 +940,9 @@
make_gap (outgoing_nbytes - GAP_SIZE);
UNGCPRO;
+ /* Count newlines in string text. */
+ NL += count_newlines (SSDATA (string) + pos_byte, nbytes);
+
/* Copy the string text into the buffer, perhaps converting
between single-byte and multibyte. */
copy_text (SDATA (string) + pos_byte, GPT_ADDR, nbytes,
@@ -1001,6 +1020,11 @@
record_insert (GPT, nchars);
MODIFF++;
+ /* Add newlines from new text. */
+ NL += count_newlines (text_at_gap_tail
+ ? (char *) GAP_END_ADDR - nbytes
+ : (char *) GPT_ADDR, nbytes);
+
GAP_SIZE -= nbytes;
if (! text_at_gap_tail)
{
@@ -1138,6 +1162,9 @@
emacs_abort ();
#endif
+ /* Add newlines from gap. */
+ NL += count_newlines ((char *) GPT_ADDR, outgoing_nbytes);
+
record_insert (PT, nchars);
MODIFF++;
CHARS_MODIFF = MODIFF;
@@ -1340,6 +1367,9 @@
combining. */
if (! EQ (BVAR (current_buffer, undo_list), Qt))
deletion = make_buffer_string_both (from, from_byte, to, to_byte, 1);
+
+ /* Do not count newlines from deleted text any more. */
+ NL -= count_newlines ((char *) BYTE_POS_ADDR (from_byte), nbytes_del);
GAP_SIZE += nbytes_del;
ZV -= nchars_del;
@@ -1360,6 +1390,9 @@
if (GAP_SIZE < outgoing_insbytes)
make_gap (outgoing_insbytes - GAP_SIZE);
+ /* Add newlines from string text. */
+ NL += count_newlines (SSDATA (new), insbytes);
+
/* Copy the string text into the buffer, perhaps converting
between single-byte and multibyte. */
copy_text (SDATA (new), GPT_ADDR, insbytes,
@@ -1470,6 +1503,9 @@
if (to < GPT)
gap_left (to, to_byte, 0);
+ /* Do not count newlines from deleted text any more. */
+ NL -= count_newlines ((char *) BYTE_POS_ADDR (from_byte), nbytes_del);
+
GAP_SIZE += nbytes_del;
ZV -= nchars_del;
Z -= nchars_del;
@@ -1489,6 +1525,9 @@
if (GAP_SIZE < insbytes)
make_gap (insbytes - GAP_SIZE);
+ /* Add newlines from replacement text. */
+ NL += count_newlines (ins, insbytes);
+
/* Copy the replacement text into the buffer. */
memcpy (GPT_ADDR, ins, insbytes);
@@ -1737,6 +1776,9 @@
adjusting the markers that bound the overlays. */
adjust_overlays_for_delete (from, nchars_del);
+ /* Do not count newlines from deleted text any more. */
+ NL -= count_newlines ((char *) BYTE_POS_ADDR (from_byte), nbytes_del);
+
GAP_SIZE += nbytes_del;
ZV_BYTE -= nbytes_del;
Z_BYTE -= nbytes_del;
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-17 15:05 ` bug#16830: " Dmitry Antipov
@ 2014-03-17 16:39 ` Eli Zaretskii
2014-06-22 16:50 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-03-17 16:39 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 16830
> Date: Mon, 17 Mar 2014 19:05:27 +0400
> From: Dmitry Antipov <antipov@dev.rtsoft.ru>
> CC: 16830@debbugs.gnu.org
>
> On 03/10/2014 10:58 PM, Eli Zaretskii wrote:
>
> > It would be nice to be able to turn the cache on and off dynamically,
> > depending on the actual line length of the buffer. I tried to
> > implement this, but my naive implementation didn't work well, because
> > sampling of the lines tends to be extremely un-representative. If
> > someone can come up with a smarter implementation, please show it.
>
> What if we just maintain the '\n' counter per each buffer text?
How would you know how many newlines are there in the buffer?
Counting them is an overhead in itself that we currently avoid (see
line-number-display-limit).
But anyway, feel free to implement something and test it. As I've
written above, I tried (for admittedly short time), but didn't get
good results.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#16830: [Bug] 24.3.50; massive slow down in forward-line
2014-03-17 16:39 ` Eli Zaretskii
@ 2014-06-22 16:50 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-06-22 16:50 UTC (permalink / raw)
To: 16830-done
> Date: Mon, 17 Mar 2014 18:39:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16830@debbugs.gnu.org
>
> > Date: Mon, 17 Mar 2014 19:05:27 +0400
> > From: Dmitry Antipov <antipov@dev.rtsoft.ru>
> > CC: 16830@debbugs.gnu.org
> >
> > On 03/10/2014 10:58 PM, Eli Zaretskii wrote:
> >
> > > It would be nice to be able to turn the cache on and off dynamically,
> > > depending on the actual line length of the buffer. I tried to
> > > implement this, but my naive implementation didn't work well, because
> > > sampling of the lines tends to be extremely un-representative. If
> > > someone can come up with a smarter implementation, please show it.
> >
> > What if we just maintain the '\n' counter per each buffer text?
>
> How would you know how many newlines are there in the buffer?
> Counting them is an overhead in itself that we currently avoid (see
> line-number-display-limit).
>
> But anyway, feel free to implement something and test it. As I've
> written above, I tried (for admittedly short time), but didn't get
> good results.
No further comments, so I'm closing this bug, as I see no further
place for improving the performance of the cache.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-06-22 16:50 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-21 12:16 bug#16830: [Bug] 24.3.50; massive slow down in forward-line Stefan-W. Hahn
2014-02-21 12:32 ` Eli Zaretskii
2014-02-21 15:51 ` Stefan-W. Hahn
2014-02-21 17:50 ` Stefan Monnier
2014-02-22 8:38 ` Stefan-W. Hahn
[not found] ` <20140222083926.GC27381@pille.home>
2014-02-22 9:18 ` Eli Zaretskii
2014-02-22 11:08 ` Stefan-W. Hahn
2014-02-22 11:29 ` Eli Zaretskii
2014-02-22 11:36 ` Eli Zaretskii
2014-02-22 12:33 ` Stefan-W. Hahn
2014-02-22 12:55 ` Juanma Barranquero
2014-02-22 15:06 ` Stefan-W. Hahn
2014-02-22 13:05 ` Eli Zaretskii
2014-02-21 7:43 ` Stefan-W. Hahn
2014-02-23 18:04 ` Eli Zaretskii
2014-02-22 12:27 ` Stefan-W. Hahn
2014-03-10 18:58 ` Eli Zaretskii
2014-03-11 8:08 ` martin rudalics
2014-03-11 17:03 ` Eli Zaretskii
2014-03-12 14:12 ` Stefan Monnier
2014-03-16 16:32 ` Eli Zaretskii
2014-03-17 15:05 ` bug#16830: " Dmitry Antipov
2014-03-17 16:39 ` Eli Zaretskii
2014-06-22 16:50 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).