Seems like the original issue is fixed already (apparently by rBd3160f350de2)

I can confirm, but not completely.

@Sergey Sharybin (sergey) might want to check on this?

ASAN output is P858

track->markers is garbled.
Will run through ASAN next

Just run a test with the "Default" Color Management. The fps was 11 to 13 fps. So the performance is better, but I don't think this is the main issue here.

This sounds very much like an issue with colormanagement. In 2.80 the default view transform is Filmic. In order to display movie clips correctly the correct mapping has to be applied first. This happens during playback. So once the clip has been played back once, the movie was "converted" internally to the correct view transform. That's why playback is realtime the second time you play it.
You can also set View Transform in Color Management panel from "Filmic" to "Default". That should give you better playback performance right from the first play of the movie.
(Sidenote: "Default" is really not an adequate term anymore, since it isn't even the default setting! :)

I have tested this with a cache setting of 1024 MB. It prefetches a video (not the video from above), could not see any GUI freezings and the progress bar updates.
But the frame rate is low: around 4 to 9 fps. (I see this in a 3d view port in the left top corner of a camera view).
If I play the video (play button, not prefetching) the frame rate is also 4 to 9 fps. But the second time I play it, the part that was "played" plays now with 24 fps.

Just as info for others. To reproduce it in the file, you just have to click "Constraint to F-Curve" in the constraint now.

Here is it the blend file:

Please provide some .blend file that allows us to easily reproduce the issue.

@Sebastian Koenig (sebastian_k), did i get it correct:

My colleague just tested this on Windows10 with the most recent Blender 2.80 build.
While it does prefetch the footage, it does act a bit weird. The interface seems to freeze until the prefetching is done. Unlike in your case however the footage is in memory after prefetching is finished.
Even though the GUI is a bit unresponsive, we could still press the little X in the prefetching progress bar to cancel it. It works pretty much the same as on my Linux system. Our systems are quite good though (32GB, Hexacore). 4GB of system memory is far from ideal for motion tracking, so poor system performance might play a role in your case. Still, I can't really see a bug here.
However, responsiveness when caching movie files could definitely be improved. When prefetching image sequences the interface stays fully repsonsive here, and the way the progress bar is reporting the prefetching progress is more realtime and repsonive as well.
When 2.8 is more stable and there is a bit more time for polishing this might be something to look at, @Sergey Sharybin (sergey)?

That would be fine, although I use Detect Features more than I use the Track Setting as Default or Copy Track Settings.

Ah, good one. Maybe instead of Detect Features? This is not used so often...

This is very nice, seems to be intuitive.

Interesting. Would be nice if some other windows user could test this. At the very least I'll have my colleagues in the office test this on monday.

Ram 4096 MB. Set the value to 3072 MB (good thinking, btw). But still the same issue.

How much RAM do you have, and what's set in your User Preferences, in System>General>Memory Cache Limit? If you prefetch and watch your System's memory consumption, is your RAM filling up or not?

As described above I use Windows 7. It freezes for a while, then the GUI is responsive again. But the prefetch of the footage didn't happen at all.

I don't see a bug here. It's true, Blender does become unresponsive for a moment, but that's just due to the prefetching of the movie file. Prefetching image sequences works smoother. At least on my system (Linux64bit) I cannot see a difference in prefetching between 2.80 and 2.79.

I agree with you for sure that Blender's accuracy is spectacular. :)

@Sean Kennedy (hype) You have probably tracked in way more programs than me, but at least in the handful of tracking programs I tried none of them had the same approach to super accurate supervised tracking like we have eihter. I think in Blender the single marker plays a more important role by itself than elsewhere, so I think it's fine if UI reflects that.

I'm excited to see these tools in the topbar to see how it really feels in action.

I am not sure about merging the track settings to just one panel. It would be a regression to 2.79, where we have those settings separated.

Would it be possible to only have one set of Track Settings? Whatever it is set to when you create a new track, that's what the new track uses. If you have a track selected, those controls then apply to that selected track. It's confusing having two, and this would streamline it quite a bit.

This sounds right to me. Makes the Clip Editor nicely consistent with the other Editors.

This got fixed by rB9b8d479e414.

I have changed some of the shortcuts.
The Alt key is now being avoided, because on a Mac it is not as comfortable to reach as the shift-key.
So:
Tracking Pie: 'E'
Setup Marker: 'Shift + E'
Setup Display: 'Shift + D'
Setup Tracking Scene: 'Shift + W'
Solve: 'Shift + S'
I find these very comfortable to reach and execute.
Compared to the clip editor hotkeys in 2.79 we would sacrifice Shift+D, which was used for the 'Disable Marker' Hotkey.
However, that operator is in the Tracking Pies at the bottom, very easy to reach.
And the 'Show Disabled Markers' toggle is now at the bottom of the Setup Display Pie, so in the same position, hence very easy to remember.
Following that logic I think we can also remove the hotkey Alt+D, currently used for the "Show Disabled Markers" toggle.
And I would vote for having the tracking pies enabled by default.

Thanks a lot for the feedback!
I agree about the lacking feedback for a toggle in a pie menu possibly being an issue. However, I would like to keep most of them because it makes the workflow so much faster. And they still can be used in a gesture style interaction, contrary to some other pie menues from the community, where there are multiple entries pre pie-slot, something I consider opposite to the idea behind our pie menu implementation. But I'll have a look again and see if some can be replaced.
About hotkeys, well, the left side is pretty crowded. Q, W, A, S, R, D, X, C are all taken. I find combinations of Shift and E, W, S still very easy and comfortable to execute with the left hand. I was about to say the same about Alt+E as well, but I am typing this reply on my macbook, and there the Alt key is in a less comfy place. So I'll have a look at the keys again. :)

This seems generally ok I think.

...in particular, I do not think that an error message is a good solution for a problem. I would better disable that button (or hide it) in case Cycles is not used. What is still missing, I think, is a button that simply put the solver constraint on the camera (without anything else related to adding objects to the scene I mean).

I do not think it can be considered "resolved": the commit considered as the Fix, as far as I understand, works only with Cycles, and I (and I think a lot of people like me) do not understand how to switch the Motion Tracker to Cycles (switching it in the render tab does not work).