поцоны, чем пользуетесь при поиске мемори ликов?

Я юзал патченый руби и профайлер

https://github.com/SamSaffron/memory_profiler ?

а что за патченый руби

Я чёт другое юзал

вообще мне кажется на это даже тесты можно было бы писать, типа before = Profiler.megabytes do_something invoke_gc after = Profiler.megabytes expect(after).to be less_than before

https://github.com/ruby-prof/ruby-prof/blob/master/README.rdoc

Там и про патчинг рубей

Вот как раз оттуда kcachegrid какой то юзал

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

вообще мне кажется на это даже тесты можно было бы писать, типа before = Profiler.megabytes do_something invoke_gc after = Profiler.megabytes expect(after).to be less_than before

Я думаю такое хуевый подход, но не могу объяснить)))

Я думаю такое хуевый подход, но не могу объяснить)))

ну ладно, перед before = ... тоже надо вызвать гц

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

ну смотри

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

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

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

это раз

два - ты не ебеешь как вызывается gc в рубях

(ну точнее ты читал что он есть, что ЯП работает так что его вызывает, но точно не знаешь когда и как)

http://ruby-doc.org/core-2.2.0/GC.html#method-c-start

типа как я понял тут можно полный гц запустить

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

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

>(full_mark: true, immediate_sweep: true) боль связана с тем что полный гц фризит приложение

если интересно как работает память в рубях, вот https://www.schneems.com/2015/05/11/how-ruby-uses-memory.html

ну и если ты руками вызываешь GC то ты явно что-то делаешь не так

ну в целях тестирования

и утечка собственно происходит именно когда GC не может высвободить память

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

а ты уверен что GC удалит данные твоей функции?

ну да, в этом проблема. Но > (full_mark: true, immediate_sweep: true) утверждают что да

ну кароч я думаю в тестах такое юзать - хуета получится

вполне возможно

но имхо мемори лик это такая штука которую в потенциале можно тестить

типа тесты подтверждают что-то, в большинстве случаев, что что-то работает. бывает, что подтверждают, что какой-то баг с прода не возникает (в принципе тоже относится к первой категории)

нет смысла тесты писать, которые могут давать фолс позитив, то есть баг на проде будет, а тесты будут проходить

но имхо мемори лик это такая штука которую в потенциале можно тестить

я ж говорю если б это было бы просто включение GC то не было бы столько нытья про текучесть сайдкика к примеру

нет смысла тесты писать, которые могут давать фолс позитив, то есть баг на проде будет, а тесты будут проходить

то что ты описал - это фолс негатив =) фолс позитив - это тесты показывают ошибку, а в проде ее нет

я понимаю, что это немного нелогично, но думай об этом как "сработали алярмы тестов"

ок, тогда фолс негатив

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

я ж говорю если б это было бы просто включение GC то не было бы столько нытья про текучесть сайдкика к примеру

дак сайдкик не течет. течет твой код, который в сайдкике выполняется

ну да, но винят в этом сайдкик

лол

заменили один ЯП на другой, переписали воркеры - ТЕК САЙДКИК

аххаха

ну и как обычно путают memory leak с memory bloat

ну так это ваш код, библиотеки, которые вы используете

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

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

Гц может забить на очистку

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

ну если это тест, гипотетически

retained memory by location ----------------------------------- 45024 /Users/<username>/.rvm/gems/ruby-2.4.0/gems/newrelic_rpm-5.0.0.342/lib/new_relic/collection_helper.rb:41 when String then String.new(object) # convert string subclasses to strings

ХММММММ

почему нет?

redirect_to account_path && return unless ... работать отказывается

а вот с set_variables хер поймешь что происходит

видел код который довел это все до абсурда

А чего не if else

Вот надо чтобы не вызывалась

Строчки экономишь?

Рубокоп ругаться будет

Мде

Можно коллбэком еще

redirect_to account_path && return unless ... работать отказывается

Тут же выполняется redirect_to (account_path && return) из за того что && высокоприоритетный. В итоге просто ретурн и до редиректа не доходит

Замени на and

Можно коллбэком еще

монадами

У and ниже приоритет чем у &&

redirect_to account_path && return unless ... работать отказывается

хммм... redirect_to path and return работало. Но как то выглядит это... не нравится мне

Вот с and работает, да. Но рубокоп тоже против

Тут же выполняется redirect_to (account_path && return) из за того что && высокоприоритетный. В итоге просто ретурн и до редиректа не доходит

Спасибо, что объяснил кстати про end. Было интересно, но я спрашивать не стал

Вот с and работает, да. Но рубокоп тоже против

Тогда только скобочки помогут

Я б иф лучше б вьебал

Не люблю unless

Не люблю unless

сразу видно похапешника!

да впизду, второе условие добавляется и ебешь голову с && или ||

только вот вроде редирект у тебя всегда выполняться будет

Щаз проверим

Проверять не надо

да впизду, второе условие добавляется и ебешь голову с && или ||

+

Было же нормально написано, стало вообще непонятно

Нет, работает нормас вроде

имхо unless норм юзать ток в однострочниках

с одним условием

сделал бы if !shop.fb_page_id? redirect ... return end your code...

return redirect unless shop.fb_page_id?

ну или да, ретурн редирект

имхо unless норм юзать ток в однострочниках

unless current_user && user_allowed_to(:edit) vs if !current_user && !user_allowed_to(:edit) vs if !(current_user && user_allowed_to(:edit))

иногда бывает нет противоположного оператора

типо blank/present

у меня вообще плохо с unless, всегда барахлить мозг начинает, когда встречаю