Телеграмм чат группы jvmchat страница 17161

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.jvm

4978 membersпожаловаться на группу

2020 June 13

N

Nick in pro.jvm

А если вот допустим есть код который работает на stream, а в спринге допустим точно такая же работа кода, но всё на for -loop

Он скажет, что это идентичный код, просто по разному реализован🤔

вопрос в упоротости и финансировании разработки)) уверен в IDEA эта фича драйвилась не один месяц и не одним человеком

источник

18:15пожаловаться #1

C

Constantine in pro.jvm

понять бы надо ли оно кому

Знаешь чего хотелось бы, чтоб например есть у меня в проекте функция работающая за O(2^n), но в зависимостях моего проекта есть спринг и в нём есть функция которая выводит такой же результат как и моя функция, но уже за O(n log n)

Так вот, хотелось бы плагинчик, который бы предлагал мне заменить свою ведосипедо-функцию на функцию из спринга, так как в спринге реализация лучше🤔

источник

18:23пожаловаться #2

N

Nick in pro.jvm

Знаешь чего хотелось бы, чтоб например есть у меня в проекте функция работающая за O(2^n), но в зависимостях моего проекта есть спринг и в нём есть функция которая выводит такой же результат как и моя функция, но уже за O(n log n)

Так вот, хотелось бы плагинчик, который бы предлагал мне заменить свою ведосипедо-функцию на функцию из спринга, так как в спринге реализация лучше🤔

короче миру надо писать говоноалгоритмы быстро, чтобы просто реализовать функционал, а потом подбирать оптимальные по критериям (время/память/поддержка спец фич конкретного процессора и т.п.) аналоги для замены

источник

18:27пожаловаться #3

A

Anton in pro.jvm

короче миру надо писать говоноалгоритмы быстро, чтобы просто реализовать функционал, а потом подбирать оптимальные по критериям (время/память/поддержка спец фич конкретного процессора и т.п.) аналоги для замены

звучит как идея для стартапа

источник

18:31пожаловаться #4

N

Nick in pro.jvm

Если кто начнет пилить отпишитесь)))

источник

18:35пожаловаться #5

U

UsernameAK in pro.jvm

интересный вопрос: в джаве GC достаточно умён, чтобы рефкаунтить объекты, которые не требуют обработки сборщиком мусора (например, объекты в которых не может быть циклических зависимостей)?

источник

18:37пожаловаться #6

C

Constantine in pro.jvm

короче миру надо писать говоноалгоритмы быстро, чтобы просто реализовать функционал, а потом подбирать оптимальные по критериям (время/память/поддержка спец фич конкретного процессора и т.п.) аналоги для замены

Почему сразу миру надо писать говоноалгоритмы ??

Плагинчик будет предлагать из зависимостей заменить говоноалгоритмы на супер алгоритмы🤔

источник

18:37пожаловаться #7

N

Nick in pro.jvm

Почему сразу миру надо писать говоноалгоритмы ??

Плагинчик будет предлагать из зависимостей заменить говоноалгоритмы на супер алгоритмы🤔

На супер-говно-алгоритмы))

источник

18:38пожаловаться #8

N

Nick in pro.jvm

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

источник

18:41пожаловаться #9

U

UsernameAK in pro.jvm

central hardware

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

не всегда плохой код хуже хорошего

источник

18:41пожаловаться #10

U

UsernameAK in pro.jvm

точнее всегда

источник

18:41пожаловаться #11

U

UsernameAK in pro.jvm

но не всегда имеет смысл его оптимизировать

источник

18:41пожаловаться #12

U

UsernameAK in pro.jvm

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

источник

18:42пожаловаться #13

N

Nick in pro.jvm

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

Причем для некоторых алгоритмов на маленьких данных даже может ухудшаться

источник

18:43пожаловаться #14

VS

Vladimir Sitnikov in pro.jvm

интересный вопрос: в джаве GC достаточно умён, чтобы рефкаунтить объекты, которые не требуют обработки сборщиком мусора (например, объекты в которых не может быть циклических зависимостей)?

GC работает так, что RC будет не помогать, а мешать. Многие JIT умеют превращать объекты в список полей, что, например, хорошо убирает аллокации итераторов

источник

18:52пожаловаться #15

U

UsernameAK in pro.jvm

Vladimir Sitnikov

GC работает так, что RC будет не помогать, а мешать. Многие JIT умеют превращать объекты в список полей, что, например, хорошо убирает аллокации итераторов

а как GC собирает POJO?

источник

18:54пожаловаться #16

U

UsernameAK in pro.jvm

и ещё: в теории JVM может аллоцировать объекты на стеке если видит что можно?

источник

18:57пожаловаться #17

VS

Vladimir Sitnikov in pro.jvm

а как GC собирает POJO?

Зависит от GC. Но, мне понравилось как сказал Лёша Ш: GC в Java это скорее liveness preserver, нежели garbage collector. Иными словами, большинство GC не пытаются найти мусор, а они ищут живые объекты, и копируют их в укромное место

источник

18:57пожаловаться #18

U

UsernameAK in pro.jvm

и ещё: в теории JVM может аллоцировать объекты на стеке если видит что можно?

.

источник

18:57пожаловаться #19

VS

Vladimir Sitnikov in pro.jvm

и ещё: в теории JVM может аллоцировать объекты на стеке если видит что можно?

Объекты на стеке -- нет (в Oracle JVM). Но, если VM видит, что ссылка на объект никуда не утекает (с учётом inline), то, как я писал выше объект превратится в список полей, которые уже могут либо вообще исключиться (если не используются), либо расположиться на стеке

источник

18:59пожаловаться #20