Looking under the hood

Because of some people I've met in my career, I have the importunity of looking under the hood when using method e.g. from FCL. It's one of the best things you can learn and adapt - always make sure you have at least a small idea what's going on behind the scenes.

Recently I've been playing with Parallel.ForEach so I went through the code. The very first call looks like this:

Parallel.ForEach() -> ForEachWorker<TSource, object>()

There's nothing fancy going here. But let's go deeper and investigate ForEachWorker<TSource, object>() method:
// If it's an array, we can use a fast-path that uses ldelems in the IL.
TSource[] sourceAsArray = source as TSource[]; 
if (sourceAsArray != null)
{ 
      return ForEachWorker<TSource, TLocal>( 
         sourceAsArray, parallelOptions, body, bodyWithState, bodyWithStateAndIndex, bodyWithStateAndLocal,
         bodyWithEverything, localInit, localFinally); 
}

// If we can index into the list, we can use a faster code-path that doesn't result in
// contention for the single, shared enumerator object. 
IList<TSource> sourceAsList = source as IList<TSource>;
if (sourceAsList != null) 
{ 
     return ForEachWorker<TSource, TLocal>(
        sourceAsList, parallelOptions, body, bodyWithState, bodyWithStateAndIndex, bodyWithStateAndLocal, 
        bodyWithEverything, localInit, localFinally);
}

// This is an honest-to-goodness IEnumerable.  Wrap it in a Partitioner and defer to our 
// ForEach(Partitioner) logic.
return PartitionerForEachWorker<TSource, TLocal>(Partitioner.Create(source), parallelOptions, body, bodyWithState, 
        bodyWithStateAndIndex, bodyWithStateAndLocal, bodyWithEverything, localInit, localFinally); 
because this part is really well documented, you can clearly see what steps were taken to improve performance of this method. By knowing this you can adjust your code to make sure, you're using it in the most efficient way.
 
I strongly encourage you to always read source code of libraries you're using, so you can understand all gotchas and implementation details. In less than a minute you can find something, what will help you in making your code better and faster.

Do I need to pull this branch?

One of the problems I faced during my recent work on Pumpkin was to check, whether it has to pull a new version of a repository. Using only git commands it's a nice and easy task, from C# code perspective it requires a bit more gymnastics.

Currently Pumpkin uses libgit2sharp library to communicate with each git repository so I was constrained to use its API. The first thing I thought about was to use git status command:

using (var repo = new Repository("foo/bar"))
{
    foreach (var item in repo.RetrieveStatus())
    {
    }
}

but though it gives a perfect info about status of a local repository, it doesn't touch remote. Dead end.

Another idea was to use git diff because of plenty of different overloads, which seemed to be feasible to get desired result:

using (var repo = new Repository("foo/bar"))
{
    foreach (TreeEntryChanges c in repo.Diff.Compare<TreeChanges>(repo.Head.Tip.Tree,
                                                  DiffTargets.Index))
    {
    }
}

but from the performance point of view I decided, that preparing a diff and analyzing it, is not the best option, if I can find a better one.

The easiest and the best option seemed to compare SHAs of head commits from the local and the remote. It was easier than I thought:

using (var repo = new Repository("foo/bar"))
{
    var current = repo.Head.Tip.Sha;
    var remote = repo.Branches["origin/branch"].Tip.Sha;
}

With such approach I can operate on the very basic info of a repository, without a need to call additional git command.