I have a problem with a ranking system I am using.


An online game with around 10k players calculates a real time ranking of points when a certain event occurs. Events don't occur that often, around 1 time per minute. This ranking is kept in the cache for quick calculations, sorting and access.

Now players can form groups and play against each other, but the scoring system is the same, only the ranking is based for the players in that group.

At first I created for every group a separate ranking, effectively having the same scores as the complete ranking, but with different positions in the ranking.

This is trivial because there are over 1.000 groups and every time an event occurs all the groups would have to be updated.

So what I did now is when the group ranking is requested take only the players that are in that group from the complete ranking and show them. The positions would have to be re-counted.

That re-counting is where the problem is. Because the sub-list is by-reference from the complete ranking list I cannot change the position of the player in the sub-ranking without updating it in the complete ranking, because it's just a reference.

I came up with two solutions:

  • Create a copy from the record every time it is requested and do some output caching (not very desirable because the rankings are live)
  • Create a copy and store this in a cache which is reset when an event occurs.
  • Create a sub-list with just the positions which is updated when an event occurs.

And the last solution: do the position counting in the output instead in the business side. This would be the best solution, only problem is that on some pages this text appears: "You are on position # in the ranking" where # is your ranking position. This number would be tedious to get then.

Does anybody have any suggestions to this problem?

2 Answers 2


There may be minor performance considerations involved with it, but this sounds like the sort of thing LINQ is very useful for. The basic idea is this:

var enormousList = new List<record>();

//var enormousList = ... (over 5 million records)
var subList = enormousList.Where(onerecord => onerecord.clanName == "RAGIN CAJUN");

// At this point in the program, NO filtration has occurred just yet and little processing
// power has been used.

// This enumerates the list once for the "ragin cajun" filter, so this may take a while.
var sublistCount = subList.Count(); //take note that Count is a function here, not a property. 
var pageSize = 50;
var hudDisplayPage = enormousList.Take(pageSize).Select((record, idx) =>
    return new HudPage(idx, record.clanName, record.playerName);
// for those who couldn't keep track; hudDisplayPage is now an IEnumerable (which you can use for-each on) containing
// 50 records of the list fitting the description. These are dynamic constructs; even now, hudDisplayPage hasn't
// yet been evaluated. If you want to cache one of these values so you're not doing the processing again later...
var saved = hudDisplayPage.ToArray();

This sort of system should make it relatively easy to take slices out of your data, and precache whichever ones are likely to be needed many times. Also, take note of this handy tip (but ONLY for queries that end up being a performance hit)

var saved = hudDisplayPage.AsParallel().ToArray();

That line should essentially multithread your filtration process, so that all cores of your processor are on it.

I can't say I know enough about your problem to write out its solution in code; but it seems like your issue is mainly in figuring out the list processing, against a single list you don't want to modify or copy. Hope I haven't misunderstood your issue!

  • I see what you did yeah, the record already contains all the information so I could make a copy of the sublist. But how would this scale if you have to iterate the enormousList 1000 times and pick only specific records from it..
    – Roger Far
    May 21, 2013 at 14:11
  • Any iterations that you'd be worried about doing too many times could be cached in memory using '.ToArray()'. You wouldn't want to do this for all queries - there are many cases where simply doing the calculation again is a better tradeoff than reserving a large block of memory. If the records you're keeping are all Classes/Objects, then you won't be making copies of the original object, just making a new list of references. In cases where the data is displayed once, you can pass the enumerable to the function creating the UI, in order to enumerate it to display objects.
    – Katana314
    May 21, 2013 at 14:47
  • The whole problem is, the record contains a property called "Position" which indicates the position of the user in the ranking. If you select a sublist the position property will have to be updated (otherwise it will be 2,6,9,55 etc), but because it's by reference this won't work..
    – Roger Far
    May 21, 2013 at 15:12
  • Well, that's a problem of storing data twice. If you have an array of objects, and each object has a 'myIndex' property, eventually that property will inherently be useless - you already know that object's position from its index in the array. You'd have a similar issue storing Person's with reference to 'Person friend' and including 'String friendName'. It sounds like you may need to refactor any instances in which you access that property, to instead refer to the index of the main list (or LINQ sublist) they're referring to (possibly using offsets, when referring to a page)
    – Katana314
    May 21, 2013 at 15:28
  • I did now :) It's easier to calculate the position of the user on the ranking when accessing and caching this than to calculate everybody's position when the ranking changes.
    – Roger Far
    May 21, 2013 at 15:44

As you say yourself, the best solution is to do the counting in the output, instead of storing it in the various lists. That way you don't have to store (and recalculate) the ranking numbers on each event for each (sub-)list, but you only calculate them when needed.

For the "You are on position # in the ranking" text, you could have a method in the class that represents the ranking list, like this: RankingList::getRankingOf(Player). Only if this information is costly to obtain and you only need the ranking from the overall list, you could consider caching the current ranking numbers in the overall list (as an optimisation strategy).

  • I think I will go with this solution and manually count the position of the player when the player wants this information. Probably caching it somewhere too.
    – Roger Far
    May 21, 2013 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.