Comments 19
и за сколько времени происходит полная загрузка данных? Еще можно сэкономить на времени\памяти если читать из архива сразу,без распаковки.
@Evgeniy_Lyashov, вы тут вроде бы память экономите, а вместо нормальных примитивов обёртки используете. У вас же практически в каждом методе потенциальный NPE.
Обёртки допустимы в сущностях, особенно, когда атрибуты сущности отображаются на nullable-поля в таблице.
Spark с этим справился бы в несколько строк и в разы быстрей даже на ноутбуке , за счет распараллеливания.
Ждём статьи с реальными тестами.
на статью у меня кармы не хватит, а так недавно мерились вот тут на тему сортировки файла
http://rsdn.org/forum/job/8348407.1
Думаю, что сортировка строк в файле (если я правильно понял что обсуждают по ссылке) - это немного другая задача, чем вычитка структурированного документа и сохранение сущностей из него в БД.
практически та же задача - вычитать в датасет, записать датасет. с архитектурной точки зрения никакой разницы. я вот примерно так xml от 1с "парсил" на машинке с 4 гб
не знаю как тут код нормально текстом прилепить
практически та же задача - вычитать в датасет, записать датасет. с архитектурной точки зрения никакой разницы
Лихо берёте. Почти любая программа - что-то считать и что-то записать, но есть один нюанс.
я вот примерно так xml от 1с "парсил" на машинке с 4 гб
Теперь осталось сравнить это с решением из статьи чтобы проверить что ваше "в разы быстрей даже на ноутбуке , за счет распараллеливания."
не знаю как тут код нормально текстом прилепить
В новом редакторе можете добавить блок с кодом кликнув на + в левом нижнем углу. Либо можете перейти в Markdown режим - галочка справа снизу.
Лихо берёте. Почти любая программа - что-то считать и что-то записать, но есть один нюанс.
странное заявление под статьей с кодом где программа выглядит как цикл, долбящий бедную базу по одной записи. я пытался донести, что у спарка в сортировке и в парсинге xml будут одни и те же конструкции. df.read() df.write() и не столь уж огромная разница в итоговом коде. хотя да, задачи решают эти конструкции абсолютно разные.
Теперь осталось сравнить это с решением из статьи чтобы проверить что ваше "в разы быстрей даже на ноутбуке , за счет распараллеливания."
это и так очевидно. но лично я сравнивал на 1с xml, что касается порно из статьи, так оно чему угодно проиграет, т.к. мало того что в одном потоке так еще и долбит базу построчно.
На java тоже можно распараллелить
Спасибо за статью, в принципе любопытно.
Но, блин, ваш XMLAttributeReader не пройдет никакое ревью. Это просто плохой код.
Сделайте его AutoCloseable. Тогда его можно будет пихать в try-with-resource и не надо будет думать о методе close()
У attributesToMap потеряны генерики в возвращаемом типе. На это даже IDE повесит стандартный Warning.
Зачем switch? На него, опять же, даже IDE повесит стандартный Warning за отсутствие default. Чем не устраивает простой if?
Прятать исключения - это плохой стиль. Кидайте их "наверх", пусть вызывающий класс думает что с ними делать.
Если пункт 4, то вообще не нужен Logger. Но даже если он вам таки нужен то private static final Logger ...
За return после try-catch, как у вас в getNextPart - отрывают руки. Это незнание основ. (И опять же - если пункт 4 то никакого try-catch просто нет.)
Зачем attributesToMap static? Вот зачем? думаете поможете JVM? Но компилятор, скорее всего, все равно заинлайнит этот метод. Оно только вопросы вызывает и больше никакого толку.
Киньте, пожалуйста, ссылку где почитать основы что за армагеддон случается если написать return после catch, что даже руки отрывают. И где правильно его писать? Дублировать в try и catch? В finally? В C# вроде бы в finally вообще return недопускается, значит тоже плохая практика.
https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html
"The finally block always executes when the try block exits" (c)
В Java история в том, что в случае try-catch-finally - finally отрабатывает всегда, чтобы у вас не произошло внутри try-catch.
Возник Exception? - finally все равно отработает.
Случился return внутри try-catch? - finally все равно отработает.
Если finally нету, то все еще проще (если случится Exception, то до return все равно дело не дойдет)
т.е. не нужно выносить return изнутри try-catch наружу.
Что делает код более коротким, часто уменьшает необходимость в дополнительной переменной, улучшает читабельность кода (потому что все более "локально").
Когда люди выносят return за пределы try-catch-finally, то это как раз и означает в 99% случаев, что они не понимают как работает finally. И просто инстинктивно пишут код который визуально гарантирует что блок finally выполнится до return. Что и есть не знание основ.
P.S. Про С# ничего сказать не могу. Но сильно подозреваю, что там работает в точности также как в Java.
за армагеддон случается если написать return после catch
Скорее всего, имелось то, что в приведённом коде метод в любом случае возвращает какой-то результат. Если на (n+1)-ом элементе случится исключение, то метод вернёт список из n элементов, что, очевидно, некорректное поведение.
И разве тут есть места, где исключения спрятаны? Вроде бы везде какое-то действие делается, либо в лог выводится сообщение, либо стектрейс. Прятать это разве не когда просто catch с пустым телом, вообще без действий? Или SneakyThrows какой-нибудь.
эх этот *нецензурное слово* xml.
Универсальный загрузчик XML на java. Или как загрузить файлы ГАР на 250 гб и остаться при памяти