Unusably slow performance of the editor in Linux?

Unity Engine
1

I’ve got a project that our team has been working on in Windows for quite some time now, and I’ve begun looking into porting it to Linux. I pulled the latest code from Perforce, and results have been frustrating so far. First, let me say that I’ve run projects in Unity on Linux before, on this same machine, and I’ve never seen anything like this, but those projects were smaller and they were never upgraded from asset DB v1 to v2. First, the import process took forever. Little did I know this would be one symptom of more issues to come. I ran into two directories that had the classic scenario of being named the same thing if you ignore case, so I deleted the extraneous directories in both places to avoid duplicate GUID issues. Even after that was done, it took over 12 hours to import. The same process in Windows took maybe an hour.

Now that it’s imported, I can boot it up and actually get to an editor, but it takes forever. I look at a splash screen for over an hour before the editor window pops up. It sits for a long time on a popup that says:

Unity Package Manager
Resolving packages…

After a while (about 10 minutes), I see some progress start to happen in the terminal when I run tail -f /proc/<PID>/fd/1 .

GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture GL_AMD_vertex_shader_viewport_index GL_AMD_vertex_shader_layer GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_bindless_texture GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_color_buffer_float GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragmen
t_coord_conventions

There’s a lot more than that, but it appears to be graphics card related outputs. After this, for some reason, it needs to reimport input-related C Sharp files (from InControl) again, and I have no idea why it needs to re-import this every time.

Then we sit here for a while with nothing else appearing to happen in the terminal:

Mono: successfully reloaded assembly
- Completed reload, in  2.759 seconds
Platform modules already initialized, skipping

and I’m still looking at a splash screen and the import of this one CS file. I’m typing up this thread in real time, and it sits at this step for 20 minutes. The whole time I can see this very consistent IO read of 3-10 MB/s, and the memory usage is slowly going up, so it’s doing SOMETHING, but it’s just doing it unreasonably slowly and not telling me what it’s doing.

After this, a popup box with a full loading progress bar says:

Importing (iteration 2)
Done

I see more video card related output in the terminal, and now I have a half-drawn editor window. It will stay half-drawn here for a long time, so now I’m going to go get groceries and come back.

Okay, I’m back. Surprisingly, that took less than 50 more minutes from the previous step to get a mostly functional editor window, which was not my experience in the past few days. Funny enough, today the editor feels at least mostly responsive, but the past two times I tried this, clicking anything on the menu bar or clicking anything in the Project or Console panes were very slow and unresponsive.

When trying to click play, it errors out on an access error or something incompatible in a CS file; I’m here to work through those issues. But unfortunately, instead of throwing an error gracefully, it renders the entire editor inoperable (for at least an hour; I have yet to leave it running longer than that to see if anything else happens), so I have to force quit it and restart Unity, which starts this whole issue over again.

tl;dr All this to say that I’m very frustrated with whatever is going on that makes this editor take so long to boot up, and it basically grinds all productivity to a halt. I’d appreciate any help that anyone can offer. I’m not at liberty to share my code base, but I can provide any logs that might give some insight. Any ideas? I’m on Unity 2019.3.14f1, Kubuntu 18.04, and I’ve got a fairly high-end machine with a GTX 1080 and the 440.100 proprietary drivers.

2

So I made a few code changes, saved, and went back to the editor, and Unity does its import process on the files I just changed. I’ve seen this a million times. But this import process is, once again, very slow. I never saw it this slow on Windows or on my other Unity projects on the same machine. A quick Google search tells me the ~10 MB/s read speed I’m seeing in my performance monitor is about 1/10th of what my 7200 RPM HDD should be able to output. Is there some throttle on my read speed turned on somewhere here?

3

First off, sequential HDD read speeds are vastly different from “random” reads, where lots of different files are accessed. But I think the real issue is, if all you did was make a “couple of code changes”, why is Unity shuffling around megabytes worth of data in the first place? A few recompiled classes shouldn’t equate to that much churn. Something is going wrong where Unity isn’t being as incremental as it could be in response to small code changes.

4

Yeah, I installed the whole editor and project on my laptop, with similar specs and the same OS, and it’s not exhibiting this behavior at all. As a point of comparison, I can play high end games on both of these machines without issue, so any kind of performance problem this severe makes no sense to me.

5

On the same machine that was having problems, I re-installed both Unity and my project to my SSD (space is at a premium, so I didn’t default to installing it there). It’s working fine now. My best guess is that somehow my Unity install was messed up before.

1 Like