АртемЪ, о том, что windows любит кушать жесткий диск, сказал не я, а автор ответа. И мой комментарий обращен к нему и вообще имеет смысл только в контексте его ответа. Так что лучше спросите автора ответа, почему он так сказал. В любом случае, для меня важны не термины, а суть, которая за ними скрывается. Так что предлагаю закрыть темы про то, пишет ли пользователь на диск или система, а также пишут ли приложения на диск или вместо этого работают с системой. В эти дебри лезть лично я не хочу.
Зачем винда вообще кушает жесткий диск без разрешения пользователя? Это имеет какой-то реальный профит? Ну там не +10% скорости работы, а, скажем, +50%? Или это такая форма издевательства?
Как по мне, кушать жесткий диск должны только приложения, а ОС - просто разграничивать ресурсы.
Андрей, с чего вы вообще взяли, что проблема в HDD? Какие-то метрики смотрели, кроме виктории? Смарт? А то ведь можно просто и пыль протереть - есть вероятность, что это поможет.
К оперативке вопросов нет, это must have, а вот остальное надо смотреть, является ли узким местом или нет, и имеет ли вообще отношение к проблеме. А про HDD у вас нет ни модели, ни возраста...
Армянское Радио, Ну, я не бухгалетр. Как по мне, отчеты можно и в экселе вести. Но ставить себя в полную зависимость от софта какой-то компании, даже без возможности миграции к конкурентам, это явно ошибка, имхо.
Понимаю, что ошибка не автора вопроса. Просто мой ответ к тому, что если уж взялся наводить порядок, то нужно хотя бы наметить правильный путь решения, даже если уборку доделает другой человек, а не мести мусор под ковёр. Вот и всё. Таким образом, начало решения: 1) донести серьезность ошибки до заказчика 2) попытаться понять настоящую причину тормозов. Ну а дальше, как пойдет. Может, удастся отделаться легким испугом. Или, может, автора в итоге возьмут на какую-то должность за вкусную зарплату, всякое бывает.
davidnum95, серьезно? Ну, жилье в Подмосковье точно дороже, чем в самой Москве, как то ни странно. Но вот обычные скоропортящиеся продукты дороже в Москве, чем в остальных городах (видимо, потому что далеко возить).
Евгений Бучинский, возможно, можно оптимизировать, исключив повторения, если у вас их много. То есть нужно включить (раскомменить) сортировку массива all, и в ключевом цикле добавить что-то такое: if (i > start && all[i] === all[i-1]) continue;
Но я не уверен, что игра стоит свеч. Если повторения редкие, то это будет лишняя нагрузка, а не оптимизация.
xmoonlight, сумма 501, так что 230 и 251 не подходит.
А 230 и 271 тоже точно не подходят. Если предположить, что подходит, то что входит в 271? Очевидно, 51. Если вычесть, останется 220, куда входят какие-то два числа. И это не 100. И это не 180. Остальные мелкие в паре точно не наберут 220.
Чтобы подписаться на изменения в ответе, нужно его лайкнуть ;) Там был ninja fix. Скорее всего, подписка на сам вопрос тоже поможет отслеживать изменения.
Евгений Бучинский, миллион оттуда, что это комбинаторика. То есть задача выбрать k дежурных из n учеников. Какое количество вариантов, по-вашему, выбрать 12 дежурных из 24 учеников? Если не знаете, как считать, то загуглите "c из n по k".
Евгений Бучинский, накидал полный перебор. Даже кое-где "срезал углы". Возможно, можно как-то еще оптимизировать. Но в целом, миллион - не так уж и много.
xmoonlight, согласен. Дополню только, что при равном количестве элементов первый элемент можно зафиксировать, это снизит количество вариантов перебора до чуть больше миллиона в худшем случае (когда 12 на 12). Вполне терпимо.
Евгений Бучинский, а с чего вы взяли, кстати, что уровень - это не ранговая шкала? То есть почему допустимы операции сложения и вычитания? Может быть, условно, крутость игрока с уровнем 300 это 19, а крутость игрока с уровнем 3000 это 20, то есть разница в реальной крутости будет маленькой. Есть какие-то подтверждения тому, что это интервальная шкала? Например, игрок с уровнем 300 имеет 300 dps (дамага), а игрок с уровнем 3000 имеет 3000 dps?
