Lately, I've been playing around with Ramsey's theorem for R(5,5). You can see some examples of previous attempts here: http://zacharymaril.com/thoughts/constructionGraph.html Essence: find all the k4's in a graph/its complement and then connect another point in such a way that no k5's are formed (I know with one type of choice, mathematically it becomes improbable that you would get past 14. But there are ways around that choice and I've gotten it to run as far as 22-23 without bricking my browser.)
With new ideas, I started playing around with storing information from batch to batch. The current construction graph goes through and searches for all the k4's in a graph every time it sees the graph. I thought this was overkill, since the k4's will stay the same in the previous graph and only new k4's could show up in the connections produced by the addition of the new point. If you store the previous k4's each time you find them and then only search in the frontier boundaries that were newly created, then you reduce the number of comparisons you have to do from (n 4) to (n-1 3).
I took a shot at implementing this last night and got it to work without obvious errors. While I am going to go back after this and comb through it for any problems, the new method makes the program much much slower. Before, the program was only ~doubling in terms of time it took to do all the comparisons. Now, it is going up in what looks to be factorial time. I've gone back through and tried to ferret out any obvious errors, but I am wondering whether the new dependence on memory could have created the whole slow down.
So, with that long intro, my main question is how are the memory and speed of a program related in a web browser like chrome? Am I slowing down the program by keeping a bunch of little graphs around as JSON objects? Should it not matter in theory how much memory