P2D2::Tree/revision view constantly redraws and uses too much CPU

Issue #173 resolved
noswonky
created an issue

After recently upgrading to 0.9.12, the tree views (history and delta) seem to be repeatedly redrawing the revision list. It eventually stops (after a few hours). While it is redrawing it also uses 50% to 70% of the CPU, causing my Macbook Pro to get very hot. Here is a screen video showing the problem: http://www.youtube.com/watch?v=KhD3e-9Rbx8 Note: The video is unlisted so is only available from this link.

A little more info: I performed a merge while the view was still redrawing, and after the merge was done, the redraws stopped. I then exited the program and re-started it, and the problem did not occur. I then made a code change, exited, re-started and the problem still did not occur. I committed the change, exited, re-started and still no problem. So I'm not sure how to reproduce it.

Comments (5)

  1. Jason Harris repo owner

    Ahhh... Its a potentially serious problem although I have never come across it myself. Since I can see it in your video, its clear that some combination of factors came into play to cause this. However since its not reproducible I will have to close this bug report for now. If anyone else comes across something like this then please take as much detail down about this repository as you can.

    Quick, make a zip copy of the repository and if possible make it available to me... If not note down details like:

    1. Which hosting service is this with, (bitbucket, googlecode, private server, etc...)
    2. What was the operation that you did just before the repository reached this state
    3. Can you reproduce the error in a finder duplicate of the repository
    4. Does a restart of the machine help, etc...

    In any case thank you very much for the report and the video. Very helpful!!!

    Thanks, Jas

  2. Jason Harris repo owner

    - Fix issue 148. We need to abandon and cut off the repository data when we switch the view to the backing view. - What was happening is that the old RepositoryData was still in existence and listening to notifications even though the document didn't point to it. Thus, when a kUnderlyingRepositoryChanged was generally posted this limbo RepositoryData was still trying to update itself. But while the limbo Repository data was trying to update itself it had problems during the update since the repository no longer existed on disk, so it asked for another update which again triggered the limbo repository to ask for an update, etc. Meanwhile the good repository that the document actually pointed to was also observing these repeated notifications to keep updating and so it flickered as lots and lots of updates took place... All of this wound the CPU right up. - Thus I think this accounts for the flicking and high CPU usage. - It also Fixes #158, Fixes #164, Fixes #173, Fixes #178, and Addresses #179.

    861c15c213bc

  3. Log in to comment