Algorithmically, one way of speeding up the process is to build an index. In your program, each (entry,feature) value is being accessed many times. How about building an index of values, with each value pointing to the number of (entry,feature) pairs with that value. Then for each (article, feature) value, you acess the (entry,feature) count directly, instead of computing it in a loop every time. The time taken to build the index will far outweigh the cost of all those eliminated loops.

-Mark

Starting with your original code

1 trial of original (37.764s total)

The first thing I did was to move everything to using lexicals. which gained a 6%.

1 trial of lexicals (35.801s total)

Next, I enabled strict and warnings. Surprisingly, this actually sped things up slightly. All the timings shown are the middle of three consectutive runs. Not scientific, but good enough I think.

1 trial of lexicals strict warnings (35.571s total)

Next, I moved from using hashrefs to simple hashes. I mentioned this to you before but here's a little show that using references unnecessarially extracts a penalty, even if only 3% or so.

1 trial of Hashes instead of hashrefs (34.850s total)

Then, as mentioned above, using hashes with continguous integer keys when an array would better do the job also takes its toll. In this case a whole 40%.

1 trial of Arrays instead of Hashes (21.070s total)

Finally, moving loops into C where possible by using perls ever-so-handy build-ins, in this case grep in a scalar context gets another 33% speed up.

1 trial of Using scalar grep to count occurances (14.281s total)

Here's my version with all the changes above. I tried to retain everything as near as possible to your original including having the arrays start at 1. Moving this to zero-based arrays, (or possibly using the deprecated $[) would probably gain another 1 or 2%.

I then got to thinking about trying to improve things by creating a lookup hash to prevent the need to search.

This is complicated by the need to compare both keys (indices) and values and further by the "any three from ten" factor. After several aborted attempts, I came up with the implementation below that creates a hash using keys that contain each combination of 3 indices and the corresponding 3 values, stringified, for each of the Articles. The value is an array of articles from which that key is generated.

The detection loop then contructs a key from each combination of each of the Entries and looks that up in the hash. This reduces the number of nested loops, but the generation of the combinations and stringification mean that the benefits are not as great as you might hope for.

Originally, I was generating the combinations for each set of keys/values, but then realised that as it is always 3 from ten, I could get away with generating a single set of indices, and then use this over and over in array slices to extract the values. Once that had dawned on me, I achieved another 25% speed up over the previous best.

This accumulates to an overall saving of around 70% from your original, on sets of 100 x 2000 which isn't too bad and is probably enough to warrent the extra compexity.