Speeding up test runs for devs with a huge amount of story table rows

[plocket]

Problem

Currently, every page visit goes through all the story table rows to find a match between a field and possibly multiple story table rows. I think there are ways we can speed this up. We already have someone trying to use 800 rows in one table.

Ideas

Better field name guesses

First of all, we can get rid of the outer loop completely if we can narrow down our guesses to the right one. I propose we do this when we first create the data for the fields. We usually only have one guess anyway, but sometimes we have two or three guesses, which could be multiplying the time significantly.

First thing to know is that a variable's name is in the DOM as part of the input field's data. It's encrypted, though, and sometimes it has multiple encryptions. Decrypting stuff that's already decrypted, though, will get characters that aren't valid var name characters. If my assumptions are correct, we can detect when we get invalid characters and take the result just before that. I'm not sure my assumptions are correct...

That way, though, we'd only have to loop through a story table once.

Break on non-proxy field guess

If a field name doesn't use proxies, we can break as soon as we find one matching row.

ALKiln/lib/scope.js

Lines 896 to 905 in 704ff12

	if ( this_row_matches_this_field ) {
	rows_that_match_field_names.push( table_row );
	// Check this until the value is set to `true` (if it ever is)
	// If the field uses proxy variables - x, i, j, etc, flag it. See "proxies" note.
	uses_proxies = uses_proxies || guess.var.match( proxies_regex );
	if ( table_row.trigger === scope.trigger_not_needed_flag ) {
	trigger_might_be_needed = false;
	}
	} // end if this_row_matches_this_field

We'll lose our ability to warn the user about multiple matches in those cases, so that's something to consider.

Break on matching trigger variable

We can do a similar break if we find a true match with the trigger variable. That would have to be added into the same area. Again, we wouldn't be able to warn the user about multiple matches in those cases.

Knock-on effects

Since we could only sometimes warn users about multiple matches, there's an argument that it would make warnings inconsistent. I'm not sure that's completely correct, though. The warnings we'd be giving would be for multiple rows for inexact matches, which I think it is different enough that it wouldn't add confusion.

These would only help speed up tests under specific circumstances, but that still seems worth it. I can't currently think of any other improvements we can make.