джава конфиг медленне в несколько раз

Ты серьезно?/

точно говорю

Хмл быстрый на ровне с джава

Аннотации сильно проигрывают в скорости

Сам подумай

Сканировать класспафф или читать файл

мы ведь не о скане говорим

а вообще в принципе о старте приложения

Автоскан = долгий старт

аннотации по скорости не уступают хмл

да, именно о времени старта

а здесь думать не нужно

бенчмарки уже есть

осталось только посмотреть на результаты

Бэнчмарки ?

— «Even so, my recommendation is to lean on automatic configuration as much as you can. The less configuration you have to do explicitly, the better. When you must explicitly configure beans (such as when you’re configuring beans for which you don’t maintain the source code), I’d favor the type-safe and more powerful JavaConfig over XML. Finally, fall back on XML only in situations where there’s». — «As I mentioned earlier, JavaConfig is the preferred option for explicit configuration because it’s more powerful, type-safe, and refactor-friendly. That’s because it’s just Java code, like any other Java code in your application». — «But there’s another option for bean wiring that, although less desirable, has a long history with Spring. Since the beginning of Spring, XML has been the primary way of expressing configuration. Countless lines of XML have been created in the name of Spring. And for many, Spring has become synonymous with XML configuration. Although it’s true that Spring has long been associated with XML, let’s be clear that XML isn’t the only option for configuring Spring. And now that Spring has strong support for automatic configuration and Java-based configuration, XML should not be your first choice».

самый объективный способ сравнения времени - замеры времени

разве нет?

spring in action 4

На каком проекте делались замеры

Два-три бина?)

при большем количестве бинов линейно возрастет время старта для обоих способов, разве нет? ты ведь не сканишь контекстом с самого рута

Время выполнения тасков будет диким, если на хмле все писать, по сравнению с аннотациями

единственный плюс хмл конфига это подмена бинов

не могу представить ситуацию, когда ты пишешь приложения на спринге и решаешь отказаться от спринга

без удаления джава кода

Просто разбираться во всем этом будет сложнее

если спринг используется не только для DI, конечно

А интерфейсы не дают подмену бинов?)

А интерфейсы не дают подмену бинов?)

Владимир имел ввиду подмену бинов без перекомпиляции

но это встречается все реже и реже

настолько редко, что не встречается

если спринг используется не только для DI, конечно

Так и использую)

Ну писать тесты на хмл это извращенно чутка

А так даже не представляю зачем еще бы это понадобилось

Ребят, один вопрос. EJB сейчас кто-нибудь использует на практике?

Тесты?

Да, используют

На wildfy многие

Да, используют

Ого, спасибо. А где?

Знаю пару федеральных проектов

Егисз

Колхозные конторы

Как правило)

Ходил туда на собесы, слава богу не взяли

По мне так лучше в это не лезть)))

А то начинается все с ежб, а кончается джавкой 1.4

В Казахстане e.gov.kz на них построены.

Знаю, так как работал над одним из подроектов эл. правительства.

Ребят, один вопрос. EJB сейчас кто-нибудь использует на практике?

Вотъ

Колхозные конторы

Ну хз

Ну которые идут в ногу со временем давно на 8 джаве и последних спрингах

А которые поддерживают очень старый продукт

Как раз такие чаще всего и на ежб

А Java8 и EJB - это несовместимые вещи?

Где ежб ни разу не видел 8 джавки)))

Даже 7)))

Может я так по собесам ходил

Но из 3х контор ни 1

Всмысле из 3 с ежб, ни 1 с джавкой выше 1.6

А Java8 и EJB - это несовместимые вещи?

В теории совместимы, на практике таких проектов не видел

Java8, wildfy10, версию ejb не помню

Проект с которым пришлось столкнуться мне

Как можно настроить чтоб логи с эрорами варнингами и фаталами писались в error.log. Данная тема не работает почемуто log4j.rootLogger=console, stdout log4j.logger.ERROR=WARN, error log4j.appender.error=org.apache.log4j.RollingFileAppender log4j.appender.error.File=${catalina.home}/logs/error.log log4j.appender.error.MaxFileSize=10MB log4j.appender.error.MaxBackupIndex=10 log4j.appender.error.layout=org.apache.log4j.PatternLayout log4j.appender.error.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n log4j.appender.error.Threshold=WARN

Подскажите, я сравниваю запросы сиквельные

один и тот же запрос через джойны и через вложенные запросы

ERROR: S client not available

через Explain plan

там есть параметр "cost", в чем он выражается вообще?

чет не нагуглилось

запрос на джойнах кстати стоит на одну единицу больше, а выполняется на 16 мс быстрее

у тебя мало данных, поэтому джоины обгоняют по скорости. на больших объемах будет наоборот

тещу на трех таблицах по 400 строк в каждой

это мало данных?

для БД это очень малые объемы, на таких разницу в скорости для любых запросов трудно заметить

до скольки таблицу забить чтобы было хорошо заметно? я вчера пол дня писал эмулятор работы проекта, могу засрать ее по самое самое

угу, на таблице по 2к строк джоин стал значительнее медленнее подзапросов

там есть параметр "cost", в чем он выражается вообще?

Кост - это результат некоторой функции. Функция принимает большое количество разных параметров, например количество считываний из памяти, с диска.

У оракла есть куча документаций, объясняющих как это работает

Для других субд принцип такой же

Важный пункт - не всегда лучший план обладает самым маленьким костом. Примеры есть в оракловых доках.

до скольки таблицу забить чтобы было хорошо заметно? я вчера пол дня писал эмулятор работы проекта, могу засрать ее по самое самое

тыщ 300 строк поставь, будет явно видно

я думаю и 300к "маленькая бд"

но думаю и так понятно, что с увелечением объёма разница в скоростях будет заметна сильнее, если ты даже на 2к заметил

как раз таки джойны будут быстрее where со временем

т.к. идет оптимизация со стороны базы

склеивать большие таблицы, особенно где много джоинов, должно быть тяжелее

хотя принято считать, что вообще одинаково

запрос на джойнах кстати стоит на одну единицу больше, а выполняется на 16 мс быстрее

на cpu и logical reads принято смотреть вроде

я думал что оптимизация со стороны базы идёт за счёт планов, и ей всё равно, джоин или сабселект, поправте если ошибаюсь

я думал что оптимизация со стороны базы идёт за счёт планов, и ей всё равно, джоин или сабселект, поправте если ошибаюсь

да так и принято считать, но вот не могу найти на стэк оверфлоу громадный ответ, там чувак говорил, что в каких-то случаях джойны выгоднее

ну я думаю даже первокурсник сможет прикинуть, где сложность больше, хотя бы примерно

наверно в подзапросов меньше видов логических операций можно исползовать

да, вероятно подзапрос это всегда nested loop join соединение

а чем больше данных, тем медленнее работает , это тупое декартовое произведение и hash join, merge join становятся выгоднее и запрос с подзапросом станет медленнее, если жойн выберет эти метода, а запрос с подзапросом не сможет их использовать

не, сори,нагнал, не так, может переделать

привет! list. steam( )...list.steam() вложенный вызов стрима - быстрее простого цикла?

привет! list. steam( )...list.steam() вложенный вызов стрима - быстрее простого цикла?

Пиши код понятным, а не быстрым.

например такой : mealList.stream() .filter(curMeal -> TimeUtil.isBetween(curMeal.getLocalTime(), startTime, endTime)) .map(curMeal -> new UserMealWithExceed(curMeal, mealList.stream() .collect(Collectors.groupingBy(UserMeal::getLocalDate, Collectors.summingInt(UserMeal::getCalories))).get(curMeal.getLocalDate()) > caloriesPerDay)) .collect(Collectors.toList());