Во многих современных ЯП происходит плавный отказ от пре-процессора. Разработчики считают
что возможностей языка достаточно чтобы отработать такие кейсы. А споры о производительности
нивелируются если мы сравним сколько на самом деле потребляет прикладной код. И проверка
флага или переменной не будет столь значимой. Более значимо - работать в парадигме чистого
языка без предварительных аугментаций.
Василий Банников, а ну да. Согласен. На самом деле не сильно понятно что там автор считает легковесным.
Мы живем в эпоху когда мегабайты бесплаты. Их никто не считает. Мне кажется важнее
чтоб ОС была укомплектована всем необходимым.
Вот есть сообщество Генту-шников. У них вообще свой критерий легкого веса.
Игнат Соколов, поскольку хабр не занимется обучением я просто тебе дам подсказку.
Посчитай количество пар соседних символов которые одинаковы. Веди учет в перемнной.
aaaaaabbccccccccccdeeeeggggff
Вот здесь количество пар символов с будут 9 штук. Это значит 10 символов.
Если пара не получилась то сравнивай счетчик пар с максимумом. И запоминай символ
если было превышение макимума.
В конце максимум и последний учтенный символ и дадут тебе ответ.
Собственно семантика заложена в термине. Exception. Исключение. Что-то исключительное. Редкое.
Например мы работаем с файловой системой на сетевом диске и внезапно диск отъехал.
(Сеть мигнула). Не будем-же мы каждую файловую операцию снабжать кодом ошибки (как это
было в языке С ). Нам удобнее исходить из позитивного сценария.
Проверять capacity через Exception - я-бы не стал. Лучше бизнес логику закрепить тестами
и это загадочное капасити ловить на самом входе. Если это техническая валидация например
входных данных то она спокойно отбросит это кривое капасити в сторону безо всяких исключений.
NastyaNyushkova, да хранить это надо в системах версионного контроля.
GitHub как самый очевидный способ. Но это требует определенной культуры
разработки. И если вы раньше не работали то вам надо провести тренинги
для всех участников этого процесса. Поначалу бывает что людям не заходит.
Люди нервничают. Конфликтуют. Ищут простых путей. Делают копи-пасты
там где нужен merge и так далее. Вобщем эту моральную ломку вам надо
пройти.
Да если копировать россыпь мелких файлов через файловых протоколы типа NFS/CIFS то
можно и неделю просидеть с 1 терабайтом. Протокол избыточноый. Много метаинформации
передает.
Ntbackup как-то быстрее копирует - но кто его знает используют ли щас NTbackup или нет?
В Linux можно tar-ом соединять мелкие файлы в один блоб и как-то вот так повышать эффективность
использования сети для копирований.
Георгий Кузнецов, таблицу обычно создают с помощью скрипта. Типа CREATE table .... primary key. .... unique.
И вот там где стоят primary/unique - надо искать твою ошибку. Названия полей.
Я могу предположить что ты просто второй раз загружаешь данные и ловишь uniq constr violation. Но я не люблю гадать и смотреть в хрустальные шары. Я хочу видеть названия таблиц и колонок.
Многие новички впадают в максимализм. Если мы строим БД с обратной связью (грузим данные за 4 секунды) на 5 секунде хотим уже делать доступ к этой БД - то я спрашиваю что это за системая такая? Что за ТЗ которое обеспечит 3 миллиона RPC (транзакций) за 4 секунды и сразу-же пойдет запрашивать их? Что за дата-центр такое в состоянии создать? Я не знаю. Не видел никогда.
Задачи быстрой загрузки (bulk/batch load) да такие были. Но загрузить такой рандомный шум что автор придумал - можно было и в кольцевой буфер или в массив и потом в фоновом режиме спокойно положить в хеш-табличку. Даже системы реального времени не обязаны стартовать за реальное время. Всегда есть компромисс. Биржевые системы работают с сутошным циклом. Днем работают. Ночью - на техобслуживании. Вот вся ночь впереди. Ребутай систему. Грузи справочники хоть 8 часов. Время есть.
Лет 10 назад в одном из форумов рунета один юноша строил свою ин-мемори БД с нано-секундным откликом. Вобщем приводил много синтетических тестов. Но физика все порешала по другому. Нет сегодня
хорошей оперативной памяти с таким доступом. Есть кеши но они не для БД а для других дел.
Наносекунда - это кстати краеугольный камень перформанса. Если перевести на язык оптики - то
это 30 сантиметров пролёта света. Вот смотрите на свой системный блок и ищите сколько
пролетит свет за это маленькое время.
Вобщем новички вместо реальной задачи - создают себе синтетический тест и ловят на нем парадоксальные
эффекты. То измеряют производительность toString. То измеряют ре-аллокацию хеш-таблички. То
создают параллельные потоки.
