mayton2019

Это очень старая практика. Почти все сишники так делают. Для современных процессоров операции с 32х разрядным числом удобнее. А суждать до 8 бит нет смысла. Все равно регистр EAX так или иначе используется целиком.

Но 8 битные целые имеют смысл если их складывать в массивы. И еще имеет смысл ужесточать
тип когда очень важно иметь функцию которая по контракту принимает только 8 битное целое. Но это редко
бывает. Чаще мы хотим целое число пошире. Но не 64 бита. Это перебор. Это как бутылка водки против контейнера водки.

Используй пару (pair).

using namespace std;

pair<int,int> getInfo(int x, int y) {
  return { x+1, y+2 };
}

Нет таких инструментов. Утечка памяти - неформализована в терминологии Java.

Но ее последствия видны в виде невозможности освободить память в какой-то момент времени в runtime.
Причиной может быть некий глобальный статический объект который хранит в себе коллекции других объектов.
Но такое программирование не запрещено. Просто надо хотя-бы знать в лицо такие глобальные объекты. Обычно это сингтоны, бины. Поскольку они - вечные - то и GC убирать их не будет.

На ранних этапах можно делать memory-dump вашего приложения и анализировать его через Eclipse Memory
analyzer. Там в виде гистограммы публикуется использование памяти и количество объектов. Через него например
я видел как по хамски себя ведет postgres JDBC драйвер во время выборки.

Сложно обсуждать перформанс-проблему без исходного кода.

Я-бы предложил как всегда ударить кувалдой. Тоесть запустить по приложению JProfiler и просто посмотреть что он покажет. Проблемных мест может быть 3. Это чтение из базы. Второе это собственно проверки и валидации. Как они реализованы? Насколько качественно? И третье это собсно запись в БД. Используется ли JDBC-batch?

SpringQuartz, cron, view здесь вообще непричем и их наличие только путает нас и вносит новые ненужные вопросы. Лучше решать проблему как одну java-функцию с входом и выходом.

Так ты сам этот инструмент назвал. Это и есть Swagger. А точнее swagger-codegen.

https://swagger.io/docs/open-source-tools/swagger-...

UPD: Добавил линку

Скорее всего тебе нужно 2 таблицы. Users и Tasks. Вторая - дочерняя и таким образом у одного юзера есть несколько тасков или ни одной.

Это называется Нормализация БД.

Парсинг - это очень простое ТЗ которое можно привязать к опыту работы с сетью и с реальными а не учебными данными. Я думаю что такие ТЗ создают очень ленивые преподаватели и инструкторы. Которые обязательно воспользуются результатом вашего труда. Коллекция парсеров магазинов пром-товаров может быть собрана в пакет и перепродана кому-то еще.

Парсинг для самого разработчика - это дно-днищенское. Очень быстро прокачаете опыт в BeautifulSoup но кроме этого дальше расти некуда. Парсинг с точки зрения договорённостей о сетевом контракте (endpoint, Swagger, SOAP, gRPG) это тоже сплошное кидалово. Что-бы вы не дизайнили - владелец сайта в любой момент может сломать просто изменив спецификацию или дизайн. Это ставит вас в заведомо рабское положение. Вроде как работу проделали но за 1 день до релиза сайт сделал редизайн и всё зря. А никто не заплатит.

Я парсил исключительно из любопытсва. Только не на Python а на других языках. Создавал базу прокей (штук 100) и пытался работать через них в параллелизме. Типа аккуратненько. Чтоб не было очевидно. Прокси ломаются. Отъезжают. Вобщем забавно. Можно потратить кучу времени но ненадежно. Все что бесплано - ненадежно.

Мой друг парсил валютные биржи. Но не ради парсинга а ради самих данных. Это было полезно. Он гонял на них нейросетевые алгоритмы. Торговые роботы типа.

По поводу опыта работы с Selenium. Я не использовал никогда. Но я думаю что это очень полезный опыт если вы докажете что делаете любые штуки - можете пойти тестером автоматизатором в большую корпорацию. Это уже на несколько левелов выше чем парсинг сайтов. И оплата стабильная.

Вобщем как цель жизни парсинг - втопку. Но как некий опыт. Попробовать. Поймать тыщи HTTP-ошибок. Парсить разные виды респонсов - это я считаю полезно.

До 2005 года производительность зависела практически только от тактовой частоты. Покупаешь 2 процессора. Смотришь. Если в 2 раза больше - то можно предполагать что в приложениях типа рендеринга 3Д графики будет ощутима разница.

Для современного железа все стало запутано. Стали наращивать число ядер. А это значит что программист обязан писать приложения так чтобы они бились на независимые части и работали на ядрах. Мультизадачка по сути. В твоём кейсе скорее всего не будет разницы. Или будет сильно зависеть от класса приложения. Или будет разница зависеть от совокупности - процессор-кеш-объем-памяти-тип-сетевого-соединения (3G/4G/Wifi).