В первом варианте был массив четверок int или массив 128 битных элементов.
Во втором случае - два независимых массивка 64х битных элементов которые в памяти
расположены достаточно далеко и для них скорее всего не нашлось такой векторной
команды которая-бы адресовалась к паре 64 + 64.
Для такого кейса [{"1":"1","2":"}2"}, {"2":"2","3":"3"},{
есть старая задачка на собеседовании где надо парсить выражение со скобочками. По сути считать открывающиеся и закрывающиеся. В данном примере она - очень подходит. Только здесь есть одна ложная закрывающая скобочка. {"1":"1","2":"}2"}
Исправить ее можно просто игнорируя неожиданное состояние автомата парсинга. Например двойка была неожиданной. И закрывающий bracer - тоже.
Регулярки... ну такое. Для них нужна память под дерево разбора и если вы парсите терабайтный и битый JSON то много будет оверхеда.
Измерение перформанса - это великое искусство. В данном конкретном приложении скорее всего узким местом будет не игры с массивами а конкретно печать на экране printf("%d\n", c[i][0]);
поэтому из быстрых алгоритмов печать надо вышвырнуть. Или заменить ее на агрегацию результата или
думать об асинхронных и параллельных операциях записи результата в файл если уж он так сильно нужен.
Очень многие начинающие прокалываются на этом. Еще попробуй отказаться от индекса в массиве и заменить
его на "подвижный" указатель по массиву. Часто бывает что умные компилляторы умеют распознавать такой шаблон но я-бы предложил написать две реализации и сравнить.
Ну и размер твоих массивов должен меряться мегабайтами чтобы ты хоть что-то почувствовал при замерах. Иначе будешь мерять только квантовый шум.
Тут - надо шаг за шагом. Твой вопрос заключается сначала в стардартной формулировке задачи Эйлера.
И потом с утверждения
Я создал алгоритм, который сначала находит все делители чисел от 1 до 28123(хотя можно и 28123/1.5)
Ты его проверил? Есть ли какой-то тест который может быстро проверить что ты не ошибся? Я на самом деле ничего плохого пока не хочу сказать по твоему методу решения, но надо как-то двигаться более доказательно. А то получается ты вывалил на голову бедных Python разработчикам какую-то математическую идею (кстати тегнуть надо топик) и далее задаешь вопрос именно по ошибкам Python - приложения.
Я считаю нет, дорогой товарищ. Тут до Python еще далеко. Тут надо как в математике. Пристально следить за каждым statement и подвергать его сомнениям.
P.S Здесь нижнее округление идет. int(math.sqrt(i)
Это нормально? Может верхнее надо?
Второе, эти детские наивные алгоритмы будут работать против такого-же наивного сайта. Тоесть его можно обсуждать но непонятно как результат этой работы представить как нечто практически полезное.
Обычно там где танцует Go - там рядышком docker/kubernetes. Тоесть не проблема очень быстро поднять тестовую БД, наполнить ее данными и сразу прогнать все тесты по DAO.
Иного способа протестировать DAO я думаю не существут. Смысл DAO - доступаться к внешним источникам данных. Если его мокать - то это уже не тестирование DAO а тестирование логики следующего уровня. Бизнес-логики и прочее.
Лет 20 назад использовали хабы. Это такие себе IP-ретрансляторы пакетов на все порты. Репитеры по сути. Работали медленно. Флудили в сегменте. Но для 10Мbit и DOS/Windows 95 их хватало. В лаборатории университетов ставили.
Сейчас хабы как устройства умерли. Вместо них - только свитчи. Причем самое меньшее количество портов что я видел - это 4.
Условно приложения делят на statefull и stateless. Большая часть приложений - statefull (это любые клиент-банки в базой и любые десктоп приложения имеющие конфиг или реестр конфига).
Stateless - это ближе к AWS-lambdas, G-Cloud functions e.t.c. Вобщем ко всему что не помнит ни сессий ни предыдущих запросов.
Persistence - это характеристика не приложений а скорее отдельных объектов. Если объект персистентен - то он сохраняет своё состояние в БД или в файловой системе. Когда сохраняет и как быстро - это тема отдельной дискуссии. Есть много технологий обеспечения персистентности. Hibernete например для Java. И просто базовый функционал сериализации. И еще вагон библиотек. Еще часто в вебе используется. Если веб-сессия персистентна - то она может путешествовать между нодами кластера и переживать падение нод. Разумеется то место куда сессия сохраняется должно быть всегда доступно. Может быть файловая система или NoSQL dbms.
Поэтому я-бы не стал говорить о приложении что оно персистентно или нет. Просто звучит странно.
Данные из таблиц как всегда удаляются через DELETE FROM table ... но если есть ограничения констрейнтов - то надо указать опцию CASCADE.
Вообще в очень сложных и много-уровневых БД необычайно тяжело что-то удалять. Иногда удаление одной строки вызывает долгий процесс проверки зависимостей. Особенно на массовых удалениях.
Поэтому учитывая специфику системы я предлагаю вообще не удалять а просто ставить статус. Например если машина угнана, продана или лежит на свалке или разобрана за зап-части - то нужно соотв. Поменять ей владельца или статус.