Как память и скорость программы связаны с таким веб-браузером, как Chrome?

Question

В последнее время я играл с теоремой Рэмси для R (5,5).Вы можете увидеть некоторые примеры предыдущих попыток здесь: http://zacharymaril.com/thoughts/constructionGraph.html Сущность: найдите все k4 в графе / его дополнении, а затем соедините другую точку таким образом, чтобы никакие k5 не формировались (я знаю с одним типом выбораматематически маловероятно, что вы дойдете до 14. Но есть способы обойти этот выбор, и я получил его до 22-23, не ломая броузер.)

С новыми идеями яначал играть с хранением информации от партии к партии.Текущий строительный граф проходит и ищет все k4 в графе каждый раз, когда видит граф.Я думал, что это было излишним, так как k4 останутся такими же на предыдущем графике, и только новые k4 могут отображаться в соединениях, созданных добавлением новой точки.Если вы сохраняете предыдущие k4 каждый раз, когда находите их, а затем выполняете поиск только в вновь созданных границах, то вы уменьшаете количество сравнений, которое вам нужно сделать, с (n 4) до (n-1 3).

Я попытался внедрить это прошлой ночью и заставил его работать без явных ошибок.Хотя я собираюсь вернуться после этого и прочесать его для любых проблем, новый метод делает программу намного медленнее.Раньше программа удваивала время, затрачиваемое на все сравнения.Сейчас оно растет в то, что выглядит факториальным временем.Я вернулся назад и попытался найти какие-то очевидные ошибки, но мне интересно, могла ли новая зависимость от памяти вызвать полное замедление.

Итак, с этим длинным вступлением мой главный вопрос:Как память и скорость программы связаны с таким веб-браузером, как Chrome?Я замедляю программу, сохраняя кучу маленьких графиков в виде объектов JSON?Разве в теории не имеет значения, сколько памяти я занимаю с точки зрения скорости?Где я могу узнать больше о связи между ними?Есть ли книга, которая могла бы объяснить такие вещи лучше?

Спасибо за любые советы или ответы.Извините за длительность этого: я все еще глубоко погружен в идею, и это трудно объяснить в ближайшее время.

Редактировать: Вот две веб-страницы, которые показывают каждый алгоритм, с сохранением предыдущих находок: http://zacharymaril.com/thoughts/constructionGraph.html

Без хранения предыдущей находки: http://zacharymaril.com/thoughts/Expanding%20Frontier/expandingFrontier.html

Ониоба лучше всего смотреть с Chrome.Это браузер, который я использовал, чтобы сделать это, и если вы откроете панель dev с помощью ctrl shift i и наберете «times», вы сможете увидеть коллекцию за все время.

Answer 1

Память и скорость программы не тесно связаны.

Простые примеры:

• Компьютер практически без оперативной памяти, но много места на жестком диске будет порка жесткого диска для виртуального объем памяти. Это замедлит ход событий как жесткие диски значительно медленнее, чем баран.
• Компьютер построен всего баран не собирается делать то же самое. На жесткий диск идти не нужно, поэтому останется быстрее.
• Кэширование обычно занимает много баран. Это также значительно увеличивает скорость приложения. Это как работает memcache.
• Алгоритм может занять много времени, но используйте очень мало оперативной памяти. Думать о программа, которая пытается вычислить PI. Это никогда не закончится, но нужно очень маленький баран.

В общем, чем меньше оперативной памяти вы используете (за исключением кэширования), тем лучше для скорости, потому что у вас меньше шансов столкнуться с ограничениями, накладываемыми другими процессами.

Если у вас есть программа, которая требует значительного времени для расчета элементов, на которые будут ссылаться снова. Имеет смысл кэшировать их память, чтобы вам не нужно было пересчитывать их.

Вы можете смешать их, добавив тайм-ауты в кэшированные элементы Каждый раз, когда вы добавляете еще один элемент в кеш, вы проверяете элементы и удаляете те, которые не были доступны в течение некоторого времени. «Время» определяется вашей потребностью.