mayton2019

Проблема кроется в самой постановке. Боту недостаточно убегать от красных. Ему надо заранее прокладывать траекторию так чтобы при равных скоростях они оба бегали бесконечно. Я так понимаю что это будет успех.

Все прочие алгоритмы при равных скоростях тяготеют к тому что зеленый будет становится все ближе и ближе. Ему ведь надо тыкаться в углы. А все известные машинные алгоритмы ближнего действия требуют ощупывания или осязания тупиков и углов. При таком раскладе зеленый будет пойман. Или надо давать ему фору в скорости.

Из 40 человек - смотреть будут 1-2.

Остальные - полезет в youtube или Netflix.
Я не критикую саму идею. Просто может стоит подождать первой нагрузки а потом уже заняться оптимизацией по факту.

Вот ты чудак. Ты говоришь - я пишу рейкастинг. И код - кривой. Так либо ты не делай кривой. Либо скажи честно что скопировал в таком-то и таком-то интернет ресурсе.

Это наверное поможет вопроснику разобраться где там нужная функция.

Если посмотреть в историю - то JVM создавалась в 1996 году как платформа для встраиваемой техники. Холодильники. Кофеварки. Техзадание такое было. И разумеется в саму спеку были заложены ограничения которые позволят байткоду собираться даже на очень слабых машинах. Где мало регистров и мало разрядности. И мы имеем стековую машину (наподобие калькулятора МК-60) в которой принципиально нет регистровой адресации. В отличие от платформ .Net/clr где есть более современная адаптация к процессору. Вобщем если вы заходите написать код который будет friendly к SSE/AVX регистрам - то у вас ничего не выйдет. На уровне JVM - максимальная разрядность алгебраического типа - 64 бит (знаковые). Это как мне кажется наиболее сильное ограничение. И неизвестно когда спека будет расширена. Насколько я вижу Oracle и JCP очень консервативны в этом вопросе и неохотно вносят изменения в сам байткод.

Поскольку это задача из теории графов - то и решать ее нужно на языках разработки и библиотеках поддержки графов. 1 млн узлов графа - это не много для современной памяти.

Из java библиотек есть Guava, Jung, GraphT.

Решение будет зависеть от выбора технологии web server.
Автору надо сделать выбор:
- Tomcat/Jboss
- Microsoft IIS
- Apache/Php
- Node.Js

Список не полный. Но достаточный чтобы начать технический дискурс хотя бы по платформам.

Xml обычно плохо подходит для баз данных. Если тебе надо изменить 1 атрибут в 10 мегабайтном xml файле то с точки зрения xml технологий это будет - создание нового документа с изменениями. Тоесть в перспективе такая бд будет плохо держать нагрузку.

Рассмотри варианты с mongodb+json. Там разработан специальный бинарный вариант сериализации json при котором эта проблема избыточной дисковой нагрузки будет устранена.

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

Тоесть в условии задачи скорее всего не хватает деталей.

Если чистка файлов идёт на регулярной основе - то имеет смысл сделать эту папку диском и подключать через fstab. Для чистки - umount + mkfs + mount. Займет секунды.

Ещё - обратить внимание на тип файловой системы. Например zfs удаляет медленно. Возможно стоит перейти на ext4.

Все синтетические тесты которые показывают перформанс intel или AMD не имеют никакого значения для автора топика. Его жене нужен Адоб и корел. Вот нужно взять самую ресурсремкую операцию и посмотреть. Если таковой нет - то 99% все равно что брать. Тогда можно просто ориентироваться на цену или условия гарантии.

Посмотри утилиту graphviz. Она позволяет красиво оформлять текстовые файлы с вершинами и ребрами в картинки.

Посмотри графический редактор yEd. Кажется у него были плагины и API для внешней разработки.

Неудивительно. Язык "C" вобщем плохо приспособлен для обработки текста. Семантика ASCIIZ-векторов такова что для того чтобы "что-то" куда-то вставить - надо: Замерять размер строки. Замерять размер вставляемой строки. Аллоцировать память. Скопировать старую строку в новое место с изменениями.

Модифицировать строку по месту... хм.. так себе идея. Я-бы не советовал. Делает код потенциально опасным. Все таки лучше чтобы строка была иммутабельной.

Иногда человек не может распознавать почерк другого человека. Это осложняет контрольную оценку.

Первая мысль - профилирование кода. Что там медленно работает. Возможно это 1 цикл. Ну тоесть без этой информации мы не доисследовали проблему до конца. А это - непрофессионально. Надо изучить.

Второе - это "разделяй и властвуй". Карту надо резать на tiles. И рендерить только необходимое на данный момент.

В базовой комплектации интерфейс Collection позволяет извлекать объекты через iterator(). Чуть позже в новых версиях jdk - появляется последовательный stream(), который вызывает iterator. И параллельный stream, который не всегда поддерживается для всех реализаций коллекций. Например файл класса STDIN - только последователен и обернуть его параллелизмом - принципиально невозможно.
Все прочие магические методы - просто переходники или адаптеры над итератором.

Прежде чем ругать jetty - сравни работу своих сервлетов с Apache Tomcat. Может ты там боков наделал?

Подобные вещи надо делать через некое распределённое хранилище типа Zookeeper которое хранит сведенья о топологии серверов. Если пришло глобальное событие - то взвести флажок в зу-кипере типа "трафик на таком -то хосте" появился. А отвествтеный демон или скрипт будет заглядывать в этот флажок и принимать решения. Такая буферизация спасет вас от "множественных сбросов кеша" которых вам не избежать без буферизации и дедупликации событий. Говорю как разработчик поскольку в распределённых системах - это самая частая ошибка. Неучет фантомных и ненужных событий.