Closed neugchr closed 5 years ago
I have encountered this problem too (#26875), I thought it was just mapgen being INCREDIBLY slow, but I didn't understand why it only affected linux and the issue was closed even if the problem still persists.
As far as I can tell it's definitely not mapgen. The same area is affected every time when I quit the game and reload the save. That's why i believe it could be connected to map memory. That way it only suffers from slowdown when building up the memory in the first place. This is probably optimized with the RELEASE=1 tag.
not too many details, but on MacOS CDDA HEAD build suddenly is very slow while walking, exploring unexplored areas. explored areas slower too.
definately a commit broke/degraded something.
Could perhaps RELEASE=0 be set for linux builds?
Honestly since that's the only problem it shouldn't be hard at all, most likely someone broke something without noticing as pirminis said. Considering just how it literally makes the game impossible to play with and there's several active issues ( one of which a month old) this should really be bumped up in priority.
https://github.com/CleverRaven/Cataclysm-DDA/pull/26905 has introduced BACKTRACE=1. Probably it's the reason.
on Mac OS, homebrew doesn't specify BACKTRACE=0 if installing/reinstalling from HEAD:
make NATIVE=osx RELEASE=1 OSX_MIN=10.14 LUA=1 USE_HOME_DIR=1 TILES=1 SOUND=1 CLANG=1
I don't believe this is the problem. I build with the command in the OP where I didn't set BACKTRACE=0.
However, as far as I can tell, there are at least two independent sources of slowdown. 1) is described here in the OP where walking into territory not seen this session at day will cause massive lag. On a side note in the downloaded version it is was better at night so lag is clearly linked to field of view. This seems to be fixed by compiling myself. When I load a savegame that lags massively in a downloaded version I can walk around at the surface just fine with the one I compiled myself.
2) yesterday I started a new lab challenge and pretty soon I experienced lag. This is in the lab at level -5 and there is no great FOW so this shouldn't be related to the issue in 1). Also this lag remains even if going back into areas already visited.
Personally I find slowdown 2) bearable since I tend to move much slower inside the lab. But 1 tile per second when running around the overmap when there is nobody around is just a game-breaker. Has someone an idea what I could do trying to pinpoint down the issue responsible for 2)?
To be sure, check config/debug.log.
I have just the same problem!
I'm on Ubuntu 18.04 and I have the same problem.
I don't really think this needs the "need confirmation" tag considering the solution to the problem was posted in the first post?
Well I mean I don't know if the build server is set up to build with RELEASE=0 - it just seems plausible to me. I would rather argue that the issue (slowdown on linux well perhaps more specifically ubuntu) needs no more confirmation, as there are at least 6 people only in this thread that are affected.
However I think this issue has rather high priority as currently the game is effectively unplayable for many people and it should be rather easy to find out if the build server compiles with RELEASE=0 and if it does it should be really easy to fix.
Build server compiles with RELEASE=1 http://gorgon.narc.ro:8080/job/Cataclysm-Matrix/8251/Graphics=Tiles,Platform=Linux_x64/consoleFull
ccache g++-4.8 -DRELEASE -DGIT_VERSION -DTILES -DBACKTRACE -DLOCALIZE -ffast-math -Os -Wall -Wextra -fsigned-char -Werror -std=c++11 -MMD -MP -m64 -D_REENTRANT -I/usr/include/SDL2 -DSDL_SOUND -I/usr/include/lua5.3 -DLUA -I/usr/include/SDL2 -D_REENTRANT -D_REENTRANT -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/SDL2 -c src/main.cpp -o obj/tiles/main.o
editing homebrew recipe (add BACKTRACE=0 to make
params) temporary fixes the issue on Mac OS Mojave:
EDITOR=vim brew edit cataclysm
brew reinstall cataclysm
I have cataclysm installed with --HEAD
option.
I have the same lag issue when running the version from build server. And this was about one month ago. I couldn't figure what causes the lag. Since then, I have been building the game locally using:
make RELEASE=1 TILES=1 SOUND=1 LOCALIZE=0 CCACHE=1 USE_HOME_DIR=1 RUNTESTS=0 LINTJSON=0
- Install Ubuntu. [Uninstall Windows (optional, recommended).]
I see what you did there, lol I have Lubuntu, and I haven't tried running CDDA on it yet, but I'll install it later today and see if my distro has the same problems
I know that long grass was causing slowdowns before it was made non opaque, and this was due to the new lighting code I believe.
I got the same issue here. I had compiled the code myself since forever, and the game was very fast. Some weeks (maybe months) ago, the game got very slow when walking in unexplored terrain during the day.
I then changed my build to include NATIVE=linux64 and then the game became very fast again. Its something related to this flag. I just dont understand why i never needed it before.
Working command line: make -j4 TILES=1 SOUND=1 LUA=1 USE_HOME_DIR=1 CLANG=1 NATIVE=linux64 Not working command line: make -j4 TILES=1 SOUND=1 LUA=1 USE_HOME_DIR=1 CLANG=1
OS: Ubuntu 17.10 Hardware specs:
lucas ~: sudo lshw -short
H/W path Device Class Description
=======================================================
system POS-EIB85CZ
/0 bus POS-EIB85CZ
/0/0 memory 64KiB BIOS
/0/4 memory 256KiB L1 cache
/0/5 memory 1MiB L2 cache
/0/6 memory 8MiB L3 cache
/0/7 memory 16GiB System Memory
/0/7/0 memory DIMM [empty]
/0/7/1 memory DIMM [empty]
/0/7/2 memory 8GiB DIMM DDR3 Synchronous 1600 MHz
/0/7/3 memory 8GiB DIMM DDR3 Synchronous 1600 MHz
/0/5b processor Intel(R) Core(TM) i7-4790 CPU @ 3.60
/0/100 bridge 4th Gen Core Processor DRAM Controll
/0/100/1 bridge Xeon E3-1200 v3/4th Gen Core Process
/0/100/1/0 display GF119 [GeForce GT 610]
/0/100/1/0.1 multimedia GF119 HDMI Audio Controller
/0/100/2 display Xeon E3-1200 v3/4th Gen Core Process
/0/100/3 multimedia Xeon E3-1200 v3/4th Gen Core Process
/0/100/14 bus 8 Series/C220 Series Chipset Family
/0/100/14/0 usb3 bus xHCI Host Controller
/0/100/14/0/1 multimedia Webcam C270
/0/100/14/0/5 input USB Optical Mouse
/0/100/14/0/6 input Positivo USB Keyboard
/0/100/14/0/7 multimedia Microsoft LifeChat LX-3000
/0/100/14/1 usb4 bus xHCI Host Controller
/0/100/16 communication 8 Series/C220 Series Chipset Family
/0/100/1a bus 8 Series/C220 Series Chipset Family
/0/100/1a/1 usb1 bus EHCI Host Controller
/0/100/1a/1/1 bus USB hub
/0/100/1b multimedia 8 Series/C220 Series Chipset High De
/0/100/1c bridge 8 Series/C220 Series Chipset Family
/0/100/1c.2 bridge 8 Series/C220 Series Chipset Family
/0/100/1c.2/0 bridge IT8893E PCIe to PCI Bridge
/0/100/1c.3 bridge 8 Series/C220 Series Chipset Family
/0/100/1c.3/0 enp5s0f0 network RTL8111/8168/8411 PCI Express Gigabi
/0/100/1c.3/0.1 communication Realtek Semiconductor Co., Ltd.
/0/100/1c.3/0.2 communication Realtek Semiconductor Co., Ltd.
/0/100/1c.3/0.3 bus Realtek Semiconductor Co., Ltd.
/0/100/1d bus 8 Series/C220 Series Chipset Family
/0/100/1d/1 usb2 bus EHCI Host Controller
/0/100/1d/1/1 bus USB hub
/0/100/1f bridge B85 Express LPC Controller
/0/100/1f.2 storage 8 Series/C220 Series Chipset Family
/0/100/1f.3 bus 8 Series/C220 Series Chipset Family
/0/1 scsi0 storage
/0/1/0.0.0 /dev/sda disk 256GB SanDisk SD8SB8U2
/0/1/0.0.0/1 /dev/sda1 volume 486MiB Windows FAT volume
/0/1/0.0.0/2 /dev/sda2 volume 46GiB EXT4 volume
/0/1/0.0.0/3 /dev/sda3 volume 191GiB EXT4 volume
/0/2 scsi1 storage
/0/2/0.0.0 /dev/sdb disk 1TB WDC WD10EZEX-00W
/0/2/0.0.0/1 /dev/sdb1 volume 931GiB EXT4 volume
/0/3 scsi2 storage
/0/3/0.0.0 /dev/cdrom disk DVDRAM GH24NSC0
Do we know that EVERYONE on Linux has this issue? Do we have any confirmation of people for whom Linux builds work fine? This could be system specific some people might have the issue while others don't. It could be that when compiling yourself the compiler does some system specific optimizations that speed it up on the build system. I'm no professional, so I don't know if there is a good way to figure out what optimizations the compiler chose to perform.
@SeelenJaegerTee I am on Arch Linux x64 and I cant say that I have seen this problem but I have not done much testing to be fair. I will rebuild with the flag and see if I see any change.
Ubuntu 16.04 here and today's version is unplayable, it's been like that for quite a while.
Just as comparison of how bad it is, right now playing it with every other program closed feels worse than running the same build for windows through wine with chrome opened playing youtube videos at the same time.
It doesn't lag much when reading or sleeping, just on walking related activities.
I strongly suspect this is caused by the BACKTRACE feature, please take a look at config/debug.log If it spams huge numbers of backtraces, its a strong signal that backtrace generation is the cause.
I did the following. Yesterday evening I compiled a new version. I tried to download the prebuild binary for the version I build yesterday. In the downloaded version I created a savegame and walked around until lag became noticeable. I saved the game (create a copy and move it to the self-compiled version) and reloaded it. I walk up until my character reaches the horizontal road I walk to the left until my character aligns right before the shelter, I walk down, by the time I reach the forest lag is present and even though I stop spamming the move key the character continues to walk into the forest.
I believe this is the corresponding log entry to the loaded save where lag did reappear by the time I hit the forest. '----------------------------------------- 12:25:08.637 : Starting log. 12:25:08.637 INFO : Cataclysm DDA version 0.C-35220-g9c64430 12:25:08.645 INFO : Language is set to: 'en' 12:25:08.928 INFO : SDL version used during compile is 2.0.4 12:25:08.928 INFO : SDL version used during linking and in runtime is 2.0.8 12:25:11.456 WARNING : opendir [./mods/] failed with "No such file or directory". 12:25:32.741 WARNING : opendir [./save/Trujillo/mods] failed with "No such file or directory". 12:25:39.180 INFO : Loaded tileset: MSX++DEAD_PEOPLE 12:29:19.726 : Log shutdown. -----------------------------------------'
I load a copy of the save file in my self-compiled version. I again walk up to the road, left to the shelter and down to the forest. No lag appears. corresponding log entry '----------------------------------------- 12:37:54.598 : Starting log. 12:37:54.598 INFO : Cataclysm DDA version 0.C-35220-g9c644303cd 12:37:54.867 INFO : SDL version used during compile is 2.0.8 12:37:54.867 INFO : SDL version used during linking and in runtime is 2.0.8 12:37:57.831 WARNING : opendir [./mods/] failed with "No such file or directory". 12:38:01.363 WARNING : opendir [./save/Trujillo/mods] failed with "No such file or directory". 12:38:07.679 INFO : Loaded tileset: MSX++DEAD_PEOPLE 12:38:59.619 : Log shutdown. -----------------------------------------'
Attached is the save file and the complete log file of the downloaded version.
Trujillo.zip
debug_prebuild.zip
PS: I build with make -j4 NATIVE=linux64 RELEASE=1 TILES=1 LTO=1 ASTYLE=0 SOUND=1 LOCALIZE=0 LUA=1
just in case that is important.
@SeelenJaegerTee I am on Arch Linux x64 and I cant say that I have seen this problem but I have not done much testing to be fair. I will rebuild with the flag and see if I see any change.
I have had the problem on arch, after building it myself it was gone
Setting BACKTRACE to 0 when building on Ubuntu 18.04 fixed the issue for me.
Do you have this problem when building yourself and setting BACKTRACE to 1? Because I build with default which means BACKTRACE=1 and for me building myself gets rid of the issue despite backtrace being true.
Confirming that building myself with either BACKTRACE
state doesn't have the issue (clean Ubuntu 18.04 installation) while builds from server (checked on 8330) have the lag. Nothing useful in config/debug.log
in all three cases tested so far. Comands used:
make -j4 TILES=1 SOUND=1 RELEASE=1 LUA=1 BACKTRACE=0
make -j4 TILES=1 SOUND=1 RELEASE=1 LUA=1 BACKTRACE=1
make -j6 TILES=1 SOUND=1 RELEASE=1 LUA=1 USE_HOME_DIR=1
unplayable lag
make -j6 TILES=1 SOUND=1 RELEASE=1 LUA=1 USE_HOME_DIR=1 BACKTRACE=0
fixed it
I don't know if it's related stricly to BACKTRACE
it just fixed the lag in my case.
Looks like RELEASE=0
is identical to RELEASE=1
because it's just ifdef RELEASE
in the Makefile
.
And I can only get some lag without adding any RELEASE
while building myself. But it's a different lag because it starts right away instead of after moving several overmap tiles like it is in the downloaded version.
Thabks for the work. Now I hope whoever did this fixes it upstream.
BACKTRACE=1
causes unbearable lag even on fast machines (I can reproduce the lag here myself). The last attempt (#27023) to fix it did nothing to address the issue. Disable them by default on emitted builds, perhaps?
@kevingranade
The bug is still with BACKTRACE=0
.
In my case is the version a8a6727
from github. With compiler flags: make TILES=1 SOUND=1 LUA=1 BACKTRACE=0
The game runs more or less good (maybe a tiny lag) into the refugee center, but when I opened the door it is laggy as the hell.
My laptop is:
$ uname -a
Linux speccy-laptop 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux buster/sid
Release: testing
Codename: buster
$ inxi -F
System: Host: speccy-laptop Kernel: 4.18.0-3-amd64 x86_64 bits: 64 Desktop: MATE 1.20.3 Distro: Debian GNU/Linux buster/sid
Machine: Type: Laptop System: LENOVO product: 10246JG v: Ideapad Z570 serial: <root required>
Mobo: LENOVO model: Emerald Lake v: FAB1 serial: <root required> UEFI [Legacy]: LENOVO v: 45CN36WW date: 07/11/2011
Battery: ID-1: BAT0 charge: 36.6 Wh condition: 36.6/38.9 Wh (94%)
CPU: Topology: Dual Core model: Intel Core i3-2330M bits: 64 type: MT MCP L2 cache: 3072 KiB
Speed: 798 MHz min/max: 800/2200 MHz Core speeds (MHz): 1: 798 2: 798 3: 798 4: 798
Graphics: Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel
Device-2: NVIDIA GF119M [GeForce GT 520M] driver: N/A
Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile v: 3.3 Mesa 18.2.6
Audio: Device-1: Intel 6 Series/C200 Series Family High Definition Audio driver: snd_hda_intel
Sound Server: ALSA v: k4.18.0-3-amd64
Network: Device-1: Qualcomm Atheros AR9285 Wireless Network Adapter driver: ath9k
IF: wlp3s0 state: up mac: 74:de:2b:5b:d9:c1
Device-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet driver: r8169
IF: enp4s0 state: down mac: f0:de:f1:94:bd:53
IF-ID-1: br-75deec0343e9 state: up speed: N/A duplex: N/A mac: 02:42:97:9f:b9:a1
IF-ID-2: docker0 state: down mac: 02:42:90:15:68:ec
IF-ID-3: veth8672f13 state: up speed: 10000 Mbps duplex: full mac: 4e:b1:ce:ff:3c:9d
Drives: Local Storage: total: 1.13 TiB used: 320.81 GiB (27.8%)
ID-1: /dev/sda vendor: Kingston model: SV300S37A240G size: 223.57 GiB
ID-2: /dev/sdb vendor: HGST (Hitachi) model: HTS541010A9E680 size: 931.51 GiB
Partition: ID-1: / size: 211.27 GiB used: 175.54 GiB (83.1%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 7.91 GiB used: 130.4 MiB (1.6%) fs: swap dev: /dev/sda5
Sensors: System Temperatures: cpu: 57.0 C mobo: 43.0 C
Fan Speeds (RPM): N/A
Info: Processes: 200 Uptime: 2d 21h 52m Memory: 7.71 GiB used: 3.59 GiB (46.6%) Shell: bash inxi: 3.0.29
Do you need more data?
For those who have problems only when BACKTRACE=1
, there are presumably errors being written to your config/debug.log
, and the time taken for those errors is causing the slowness. I would rather try to fix the underlying causes of those errors, so please take a look and post some representative errors if you find them.
@mdtrooper Your issue is probably simply that you're using a debug build, which is unfortunately slow. Try a release build (or apply this change to your libstdc++).
@jbytheway Yes, thanks. I thought the RELEASE=1 was for to build a 0.c version with the last code. Sorry.
I think my PR (#27468) fixes exactly that. Issue sees to be in the standard non-conforming stdlib implementation. So it depends on the build environment.
I've just downloaded 0.C-36328-g31cd8a6 (advertised as 0.C-8406 on the build server) for linux x64 and for me the problem seems to be gone. Can this issue be closed or do other people still have this problem remaining?
Lag dissapeared after devgs fix for me. Using the latest linux x64 build from the server.
Apparently adressed by #27468
Describe the bug
Version 8421 on ubuntu 18.04.1 has incredible lag when walking into territory not yet seen this session. (see issue #26503) this effectively renders the game unplayable.
When building latest version from github with make -j4 NATIVE=linux64 RELEASE=1 TILES=1 LTO=1 ASTYLE=0 SOUND=1 LOCALIZE=0 LUA=1 the lag is gone.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Version downloaded from the build server should have optimizations turned on by default. You should not have to build the game yourself or be stuck with a version that is effectively unplayable.
Versions and configuration(please complete the following information):
Additional context
Makefile states that by default debug version without optimizations is built. Could perhaps RELEASE=0 be set for Linux builds?
EDIT: Fixed some typos.