- If you do a system profile while it’s starting, what is it doing?
- Did you build optimized/release or debug build on Linux?
- Do you have a good storage subsystem, with aligned partitions and such, on the Linux side?
- Is this every time, or only when starting “cold” (e g, could this be shader compiling?)
Hi, I’m using manjaro (Archlinux) for developing for some reason. I’ve patched glibc-dso witch is introduced here
, but my editor launch time is still slower than windows(I have double system on my labtop and one SSD), In windows it just use around 10 seond to launch editor, but it will use 2 minutes when swiching to linux, I fond that the progress number changes slower from 0% to 10% and 40% to 100% than 10% to 40%. and I use c++ a lot, when I change some code, I have to wait more 2 minutes than window, It isn’t high-effeiciency. Is there any manual setting I can do to improve launch time? thanks a lot
thank for relay!
- I haven’t change any profile of project, this project has less things to load at engine start. when I load a empty project it will use more time to load compare with windows.
- I’m using development editor selection for launching each platform, The launch time doesn’t add compile time.
- I will try aligned partitions for storage.
- Every time I launching demo project will causing 2 minutes witch is not “cold”, window “cold” launching uses 10 seconds, if it is not “cold” and just 3 seconds in windows. but linux is aways the same.
Hi, did you set the environment variable? The 2 minutes launch is consistent with the dso-patch not being applied.
export GLIBC_TUNABLES=glibc.rtld.dynamic_sort=2
Did the AUR package compile ok? I know there are some reports on it having some issues that I haven’t gotten around to figuring out yet
THis is the launch logs of second time. and I have set the system parameter for system, I fond some module use some time to init, such as " Initializing TcpMessaging bridge"
I fixed compile error of glibc-dso, and successfuly compile that patch
Yes, I paste this commond to terminal when I finished patching glibc-dso, it seems that I have to do this action when restarting OS
I can probably fix that in the AUR package…
You need to set the environment variable every time before the Engine launch… I do have a script for launching the engine that does it for me… or you can just set it globally in your /etc/profile.d or however you chose to… it should be safe…
Is this the same project, i e, your files are on a NTFS or FAT32 partition? If so, that could explain it – try hosting the project on ext4. (Of course, then you’d need a second copy for Windows.)
I still think a real system profile using a profiling tool could tell you what it’s spending its time doing.
Thanks a lot
Thanks for your “align partitions”, I re-erase my disk, SSD seems faster!
Not same project, I clone it to ext4 file system disk, I will try to use a profile tool to find out detail reason 
I disable some plugins witch cost time in that picture, It’s faster! but windows still using those modules, etc. UDP TCP and so on. my disk need “4k align” repair!, I will test it when system reinstalled.
The result is the same, When I disable some module, udp, tcp, and so on, it is faster to launch engine, the cost is not loading .so, it is module initialization!
I am in the process of setting up my system to migrate from Windows to Linux, so I haven’t tried this yet myself, but… Has anyone investigated if it is possible to use UNIX sockets instead of TCP for this inter-process communication? Also, does it seem to matter whether the editor is configured to talk to itself on the LAN address of the host vs. the loopback (typically 127.0.0.1)?
The other thing I’m wondering about is if UE is waiting until a timeout on something like reverse DNS queries of IPv4 addresses, etc. In Linux server admin, it’s common to turn off RDNS lookups for many daemons that are logging incoming connections, because they take time even when there is a record, and they often waste time to yield no result because RFC1918 private addresses as well as many transient public IPv4 addresses often don’t have any RDNS records. It could also be waiting for identd (rarely used on Linux, but some daemons still try to query it by default) or some Windows equivalent.
Once I get my Linux up and running, I’ll take a look at this and see if I can figure out what’s happening. From what I’ve read of this bug, my sysadmin instinct is to suspect UE is waiting for something nonessential (and maybe Windows-specific, n/a in Linux), and moving on as a graceful fallback behavior after that mysterious something times out. This problem doesn’t sound like resource bottlenecks to me.
Does anyone know if there’s an official bug report on file with Epic for this?
[Background: As I write this, I have reinstalled Windows onto a dedicated SSD and will be flattening the other one and installing Debian 11 as soon as I’ve validated that all my files are migrated. This will probably happen late this week, because I’ll be at my company’s data center with its extremely fast Internet pipeline – just the place to be when downloading a few hundred gig of software.]
Hey those are plugins that are mentioned there, what you are thinking of are things like swarm or metrics reporting. Swarm is not a thing on Linux(yet), and anything dns related is cashed on the system side so there is no real need for a fix.
The biggest issue is the glibc issue and the patch linked in the original question, feel free to read through the issue thread linked in the aur package. Not sure how feasible is patching the glibc on debian11…also you are stealing a formally resolved thread.
The AUR glibc-dso package now breaks the system
To fix it from the live boot media do mount your / partition and run
pacstrap -i /mnt glibc lib32-glibc