#define если if
#define длявсех for
#define аиначе else
#define ДЫРКА NULL
UPD. В этой инициативе нет ничего нового. Копмилляторы с одного на другое назывались кажется
толи кросс-компилляторы толи транс-пилляторы неважно. У тебя по сути задача решается
реплейсментом исходного кода. Только надо делать не тупой реплейсмент а хотя-бы не трогать
строковые литералы.
Я думаю что мы окажем медвежью услугу если дадим линки на GCC, clang. Это реализации компилляторов. И они сложны как вселенная. Но было-бы невежливо ничего не дать.
Тут пишем Spring а подразумеваем Hibernate. Я думаю что для Java - безразлично. Можно ссылку ставить куда угодно. Но для ORM движка и для механики Serializable - я-бы проверил не приводит ли это к зацикленности и ошибкам при работе persist/save. И я-бы попробовал null вместо ссылки на самого себя.
(Очень плохо конечно что ты ради секретности придумал имя Test. Это сильно сбивает с толку.)
pinkhead_psd, не думайте сейчас о накладных расходах. Просто попробуйте написать рекурсивный обход Б-дерева. И если он будет успешным (без ошибок) и без stack overflow - то тогда попробуйте декомпозировать в решение на базе цикла.
Но мой опыт подказывает что 80% разработки на этом завершаются. Всегда технически проще подрегулировать размер стека (для Java там есть отдельный параметр) чем платить программисту сотни и тысячи зелени за размотку рекурсии в цикл со структурой типа Deque.
В наше время - самый дорогой ресурс - это вовлеченность специалиста в задачу. Вот честно. Все стало дешево. Диски. Память. Вычислительные ноды. Как грязи всего много. А людей не хватает. И денег на оплату синьоров не хватает.
pinkhead_psd, еще рекурсия очень важна при описании различного рода грамматик. Такие технологии как BNF/EBNF, yacc, bizon, antlr e.t.c. - это все описательные языки которые объявляют какой-то синтаксис. Например синтаксис S-expressions или JSON может быть описан десятком строк описания грамматики на EBNF.
Есть описательные рекурсивные техники для рекурсивных структур данных. Например узел бинарного дерева описывается как Нода у которой есть две ссылки на такие-же Ноды. Это поддерживается даже в языке С.
pinkhead_psd, стек не обязательно должен быть использован в рекурсивной функции. Существуют технологии т.н. хвостовой рекурсии где ты описываешь функцию рекурсивно а компиллятор ее разворачивает в цикл. Но это не все компилляторы поддерживают. И сама функция должна подойти под критерии.
Есть техники описания т.н. генераторов последовательностей. Например список чисел Фибоначчи. Эти генераторы тоже имеют вид рекурсивных функций. Но при этом стек им не нужен. Они - ближе к итераторам по своей природе.
Vitsliputsli, мое послание было не в том что нельзя мерять отклик буферного кеша. А в том что новички неверно понимают себе смысл результата измерения. Они запускают свой джоб. Прогревают кеш до предела. А после этого выходят с уверенной позицией о том что все оптимизировано и проблем нет. Так обычно и происходит после серии бенчмарков.
Ничего непонятно. Какой insert or update? Есть синтаксис типа "upsert" и он поддерживается в sqlite https://www.sqlite.org/lang_insert.html https://www.sqlite.org/syntax/upsert-clause.html
ПК менять нежелательно т.к. это влияет на ссылочную целостность. ПК - это не просто поле - это точка связи между разными таблицами. Вобщем это архитектурный вопрос. Если вы решили менять - то вы себе что-то отрезали навсегда.
Тут даёшь, даёшь рекомендации, а автор сидит, ручки певесил. Он так и не сделает explain. Сидит надеется на чудо. Думает что профессионалы будут играть в угадайку. "А вот попробуй это. А это.."
На сервере через докер работают несколько прог, но за несколько дней непрерывной работы docker сжирает огромное количество места на диске (100гб)
Можно отключить все проги кроме одной и подаблюдать. Потом включить вторую и понаблюдать.
Вот так за несколько итераций можно узнать кто вредитель. Ну и дальше по ситуации.
prewordeSSS, чтобы заниматься оптимизацией нужно знать цифры. А именно - сколько всего строк в таблице. Сколько в среднем будет выбирать типичный запрос который ты оптимизируешь. Допустим это 3% от общего объема таблицы - тогда индекс будет эффективен скорее всего. Это эвристика вобщем. Так. Чисто для начала разговора.
В общем случае... если тебе не чем заняться - то я-бы предложил построить композитный индекс по полям user_id type_id и посмотреть как это влияет на время отклика. В более сложном варианте - нужно знать какой тип БД (MySQL, Postgres e.t.c.) и смотреть план выполнения.
Тестовые запуски нужно делать по холодному. Тоесть по тем данным которые еще не запрашивались. Это гарантирует честность результата. В противном случае ты будешь мерять отклик буферного кеша вместо диска. И такой результат будет красив - но в будущем не будет отражать действительность.
Оптимизация обычно - это компромисс. Тоесть ты в одном месте в БД что-то ускоряешь. В другом что-то замедляется. Ускорять везде - не получится. И еще оптимизация делается согласовано в владельцем БД. Тоесть он должен быть в курсе чем ты занимаешся.
И для оптимизации нужно запросить у владельца БД все права на оптимизацию. Сбор статистики по таблицам. Возможность дропать и создавать новые таблицы. Иначе оптимизация теряет смысл.
Ну посмотри вот в зеркало компиллятора GCC https://github.com/gcc-mirror/gcc