mayton2019

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

Это переменная которая хранит код ошибки предшествующей команды. Обычно 0 - это ок. А другое число говорит о неудаче.

Скорее всего надо запустить компиллятор и оценить масштаб трагедии. И после этого писать новое сообщение в тостер.

Я сильно сомневаюсь в наших "прогнозах" здесь в условиях отсутствия информации.

Автор не правильно формулирует задачу.

Я предлагаю словарь Python все таки оставить словарем и не искать натянутых аналогий. База данных (в общем понимании этого слова) это RDBMS с поддержкой ACID.

В противном случае, и ощипанный петух будет человеком.

Я бы предложил 2 шага.
1) построить гистограмму для всех X,Y координат раздельно. Выбрать локальные минимумы. Это будут линии таблицы. Но не точно.

2) дефекты клеток в которые попали по 2 точки можно поправить случайным образом двигая линии. Но чтоб случайность была эффективнее я бы предложил генетически алгоритм.