#198 open

effect problem

Reported by nightsuns | September 9th, 2009 @ 06:44 PM | in 0.8

Comments and changes to this ticket

  • nightsuns

    nightsuns September 9th, 2009 @ 06:46 PM

    on 0.7 version.
    if i add a comment, then click Amend, then the CPU reach 100%, then i using shark the profile, it's like this:

    9.9%    9.9%    libobjc.A.dylib objc_msgSend
    7.3%    7.3%    libauto.dylib   Auto::Zone::block_start(void*)
    4.5%    4.5%    libSystem.B.dylib   __spin_lock
    4.0%    4.0%    CoreFoundation  CFBasicHashGetBucket
    3.3%    3.3%    libauto.dylib   Auto::Zone::set_write_barrier(Auto::Thread&, void*, void*)
    2.8%    2.8%    libauto.dylib   check_resurrection(Auto::Thread&, Auto::Zone*, void*, bool, void const*, unsigned long)
    2.7%    2.7%    libauto.dylib   auto_zone_write_barrier_memmove
    2.6%    2.6%    Foundation  hashProbe
    2.6%    2.6%    libauto.dylib   Auto::Zone::get_associative_ref(void*, void*)
    2.4%    2.4%    CoreFoundation  ___CFBasicHashFindBucket1
    2.4%    2.4%    libauto.dylib   auto_zone_set_write_barrier
    1.8%    1.8%    CoreFoundation  __CFBasicHashFastEnumeration
    1.6%    1.6%    libauto.dylib   Auto::Zone::set_associative_ref(void*, void*, void*)
    1.4%    1.4%    Foundation  _NSSortFunctionMany
    1.1%    1.1%    libauto.dylib   Auto::Thread::track_local_assignment(Auto::Zone*, void*, void*)
    1.1%    1.1%    CoreFoundation  __CFStringHash
    1.1%    1.1%    Foundation  readStrongAtWithSentinel
    1.0%    1.0%    Foundation  NSKeyValueShareableObservationInfoNSHTIsEqual
    1.0%    1.0%    libobjc.A.dylib objc_assign_ivar_gc
    0.9%    0.9%    CoreFoundation  CFArrayGetValues
    0.9%    0.9%    libauto.dylib   Auto::Zone::block_layout(void*)
    0.9%    0.9%    CoreFoundation  CFArrayGetCount
    0.8%    0.8%    Foundation  _NSKeyValueReplaceObservationInfoForObject
  • nightsuns

    nightsuns September 9th, 2009 @ 07:11 PM

    • Title changed from “crash” to “effect problem”

    after a debug, i found it's not a crash, and it's so slowly at the function

    • (void) addFilesFromDictionary:(NSMutableDictionary *)dictionary staged:(BOOL)staged tracked:(BOOL)tracked

    and :
    dictionary has 2600 objects,
    i found the

            [dictionary removeObjectForKey:file.path];

    this line is very very very slow.

  • Pieter de Bie

    Pieter de Bie September 9th, 2009 @ 11:16 PM

    That's weird, a small test here shows that removing strings from a
    dictionary, even if it's huge, can be pretty fast. Did you try to time
    it? How slow are we talking about here?

  • nightsuns

    nightsuns September 10th, 2009 @ 09:09 AM

    ok, i package entry repository for you, and you can download it direct at :


    , then when you open it, it's very very slowly.

  • Johannes Gilger

    Johannes Gilger September 10th, 2009 @ 11:47 AM

    • State changed from “new” to “open”

    Hm, I've certainly located (and maybe even fixed) the bug. The problem was that when reading the filenames and inserting them into the tracked/untracked-lists, those lists would constantly resort themselves (i.e. after every file), which is what took them so long (yep, the rearrange-stuff took up almost 100% of that thread).

    I'm sending a patch to the ML and to GitHub which shows how to remedy this problem. However it may be unpretty or have other side-effects. See for github here: http://github.com/heipei/gitx/commits/bugfixes

  • Johannes Gilger

    Johannes Gilger September 10th, 2009 @ 11:50 AM

    Yep, it certainly has the side-effect that the stage/unstage-hunk stuff doesn't work anymore. Oh well.

  • Pieter de Bie

    Pieter de Bie September 10th, 2009 @ 11:57 AM

    Your problem is probably an early return, like on line 275, before
    resuming the tracking

  • Johannes Gilger

    Johannes Gilger September 10th, 2009 @ 12:01 PM

    OK, I've updated the patch.

    Besides making the stop/resumeTracking public it issues a "stop" whenever the commitController uses refresh, and resumes at the end of doneProcessingIndex.

    Everything seems to work fine with this patch.

  • Pieter de Bie

    Pieter de Bie September 10th, 2009 @ 12:05 PM

    Actually, I built it this way so that even if the index is partially
    loaded, you still have some information.

    For example, if only the unstaged changes have been loaded, but it's
    still busy loading all the untracked files, you can at least start
    committing some of the stuff. If you use this patch, won't you have to
    wait until the complete index is available before being able to do

  • Johannes Gilger

    Johannes Gilger September 10th, 2009 @ 12:10 PM

    Hm, yeah, that's right, but the way I see it is:

    1. In 99% of the cases the views loads almost exactly at the same time because you don't have many files.
    2. The rest (like this one) has one list which has a lot of entries and takes long, so the whole program is unusable even if one of your lists has already been loaded.

    Is that right? Besides, what good is a list that is loaded if the opposing one isn't complete yet, most operations have to do with shoveling things from one list to the other ;)

  • Pieter de Bie

    Pieter de Bie September 10th, 2009 @ 12:15 PM

    Well, I just thought there might be a different way to fix the issue,
    by localizing the call that causes the rearraging, and just stop
    tracking around that call. For example, by moving the
    -continueTrackingIndex call to before the return halfway in the code. That way other index stuff will continue to work in case one of the
    processes that loads the index fails somehow (which sometimes happens)

  • Johannes Gilger

    Johannes Gilger September 10th, 2009 @ 12:37 PM

    Hm, I just looked at the stop/resume thing again and the way I see it is that the only thing they do is to turn on/off the rearranging (i.e. the sorting) or the lists.

    So, worst case that could happen: Your lists don't get sorted because one the calls didn't finish.

    Anyway, I've considered this in the latest version (on GitHub):

    --- a/PBGitCommitController.m
    +++ b/PBGitCommitController.m
    @@ -186,8 +186,11 @@ - (void) updateView
     - (void) doneProcessingIndex
            // if we're still busy, do nothing :)
    -       if (--self.busy)
    +       if (--self.busy) {
    +               [cachedFilesController rearrangeObjects];
    +               [unstagedFilesController rearrangeObjects];
    +       }
  • Pieter de Bie

    Pieter de Bie September 13th, 2009 @ 03:30 AM

    The things I don't like to turn of the rearranging and then returning
    to the run loop. All sort of weird stuff can happen in the meantime,
    so it's a good thing to keep that localized to within a function.

    I liked the first idea better -- isn't it easier to just put the
    [resumeTracking] thing before the first return? We can do that, or just stop the automatic rearranging, and rearrange manually in every
    method where we change something, though that sounds dangerous :)

  • Pieter de Bie

    Pieter de Bie September 13th, 2009 @ 03:31 AM

    I've started refactoring the code for the git index to a common class,
    GitIndex. The results so far can be found here:


    It's not fully functionally equivalent with what we had first yet, but
    it's getting nicer, and doesn't depend on any GUI stuff, so we could
    actually write tests for this :)

  • Pieter de Bie
  • nightsuns

    nightsuns September 14th, 2009 @ 10:01 AM

    ok, tested, this version seens ok for me. very speedly.

  • Johannes Gilger

    Johannes Gilger September 12th, 2010 @ 12:16 PM

    • Milestone set to 0.8
    • Milestone order changed from “0” to “0”

    I think this issue has been fixed, looking at the commits from Pieter from 13.09.2009 in the gitx-repo on his pb/index-refactor branch. I'm assigning this to 0.8, but will close it soon if there are no objections.

  • dino joyri

    dino joyri December 10th, 2018 @ 01:55 PM

    i have tested this version and its running fine in my pc, i am also running heavy apps like nox android emulator , bluestacks , spring suite but i did not got any prblm

  • my estub

    my estub January 18th, 2019 @ 08:56 AM

    This is the Test Site for my-estub.com. Click Here to go to the LIVE SITE · Administration Portal Login, Privacy Policy. © Paperless Pay Corporation ...


  • Morgan Pearce

    Morgan Pearce March 27th, 2019 @ 01:39 PM

    Composing administrations have made it less demanding for understudies to take care of business in time. Expositions have turned out to be compulsory for scholastics as they represent reviewing framework. Be that as it may, you could maintain a strategic distance from the worry by contracting such administrations which could help to get you excellent papers in time at the moderate costs. college assignment help online

  • sandy
  • Tride1989

    Tride1989 June 4th, 2019 @ 12:39 AM

    If you are an avid gamer, always have a few backup controllers on hand. This is especially useful if you are always playing with a group of friends, as controllers could break or become damaged. This will help to maximize your game play and give you insurance in case something goes wrong. https://isocialhub.net/

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

GitX is the nice-looking gitk clone for OS X