@BabloUser
не могу отрицать что действительно среда
это же как надо чтобы гвоздь от шканта не отличить? все же просто, гвозьди забиваются микроскопом, в крайнем случае кулькулятором.
будет ли мое предположение верным если я представлю что данные для чека берутся из от кудато(базы данных или допустим файла)
12 миллионов врятли поместтся в ресурсе значит это база данных и если она то встроенная раз необходимо использовать исключительно бас ну или чтение из файла, я пот например ранее пытался почитать басом файл на 30ГБ, бас у меня заканчивался вместе с оперативной памятью.
для простоты допустим все-таки внутренняя база данных как и у меня на 200К+ записей
и логикак опять же, допустим такая же как и у меня - из базы берется строка, чтото происходит(гет-запрос + простая регулярка или xpath), строка в базе изменяется\дописывается/перезаписывается.
я думаю то тогда бутылковое горлышка в поиске\чтении\записи в базу.
аргументы такие - имел по выше описаной схеме, причем данные обрабатывал в три этапа, трижды искал, трижды полуал и столько же перезаписывал, при том процесс бас 3-5% на процессор немного оперативки, совсем висит, процесс базы 25-30% процессора.
решил уменьшить количество действий с базой данных, ну и раз это то в три раза, логика посредине усложнилось, обращений к базе данных на еденицу времени уменьшилось.
итак: не то бы что не весит, так подвисает конечно, но загрузка всего на 100% со всех сторон, ну дак ладно там 150 браузеров. окно программы отзывчивое и вообще замечательное. подвисает как раз в тот момент когда большинство потоков переходит в такой режим что сложная логика по средине отсекается браузер не используется и происходят частые обращения к базе данных. общяя нагрузка на системе падает а окно баса вывешивается.
вопрос как оптимизировать работу с базой данных при обработке большого количества записей, я вот понимаю что если я бы брал с базы данные большими страницами а не построчно было бы пошустрее, а как добовлять и главное модифицировать записи в больщем количестве.
