Здравствуйте, Shmj, Вы писали:
S>Если не работать над оптимизацией а писать в лоб — да. Но, конечно, если начнете составлять план запроса и т.д. — то вручную сможете добиться лучших результатов. Но такие оптимизации нужны далеко не для всех запросов.
Да, я и имею ввиду: и там, и там написать в лоб. Вариант с C# будет быстрее? Или надо одинаково заниматься оптимизацией?
Re: Неуверенные в своей востребованности на рынке труда, принижают скиллы других
Здравствуйте, Артём, Вы писали:
Аё>И только C++ макаки кидаются какашками. Только слабые программисты, которые затрудняются пройти интервью на любом языке, "ни за что не будут писать на чём-то кроме C++".
Только Артём год за годом пытается набрасывать какашки на C++.
Это какая-то детская травма? Плюсовик увёл подругу?
Re[3]: Неуверенные в своей востребованности на рынке труда, при
Здравствуйте, Артём, Вы писали:
Аё>Я перешёл с плюсов на чистую жаву на x3 больше в 2011г. Если представится возможность перейти на x2 больше на плюсы- с радостью перейду .
в 11-ом было реально перейти. Сам это делал. А сейчас, языки настолько далеко ушли, что без знания 11+14+17+20 на С++ не вернёшься. Как минимум на x3. Любой интервьювер будет рассматривать тебя на собесе после такого перерыва как джуна.
Re[2]: Неуверенные в своей востребованности на рынке труда, принижают скиллы дру
N>Да, я и имею ввиду: и там, и там написать в лоб. Вариант с C# будет быстрее? Или надо одинаково заниматься оптимизацией?
Будет одинаково. Написать на C# может быть быстрее, т.к. C# человек уже знает, а SQL — нет. Это, разумеется, все только для поверхностных и очень простых задач. Как только там шаг влево или вправо, сразу расстрел, таки придется изучить SQL, а также конкретную БД. Все как всегда: лишний уровень абстракции хорош только когда под капот не требуется лезть (потому что все идеально документировано и объяснено). Для простого кода оно так и есть, но как что-то менее тривиальное, так сразу нужно разбираться, в какой именно SQL преобразуется твое LINQ-выражение.
Re[2]: Неуверенные в своей востребованности на рынке труда, принижают скиллы дру
У меня самого глаза в кучу от их тэмлэйтов и прочего — каждый раз с трудом продираюсь через текст, чтобы понять что там за фигня творится. А в 2019 (и раньше были прецеденты) ходил к плюсовику из линуксовой команды, чтобы тот мне помог прочитать код для VC++. Не помню, что там было, но гугл не помог понять написанное — какая-то мелкософтовская специфика. Короче, плюсы у меня тягостное ощущение в желудке вызывают. Однако, я не пложу на эту тему топики и сраться не лезу — есть более важные вещи, более интересные вещи, и более цепляющие. А вот у Артёма, похоже нет.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[8]: Неуверенные в своей востребованности на рынке труда,
Здравствуйте, Nuzhny, Вы писали:
N>Я SQL не использую, но всё равно интересно. Что, прямо таки можно написать запрос на SQL и на C# и второй вариант будет ощутимо быстрее?
Для случая такого упоротого говна как SQLite это теоретически возможно. Для остальных СУБД — сомнительно.
Most SQL database engines (every SQL database engine other than SQLite, as far as we know) uses static, rigid typing. With static typing, the datatype of a value is determined by its container — the particular column in which the value is stored.
SQLite uses a more general dynamic type system. In SQLite, the datatype of a value is associated with the value itself, not with its container.
...
Any column in an SQLite version 3 database, except an INTEGER PRIMARY KEY column, may be used to store a value of any storage class.
All values in SQL statements, whether they are literals embedded in SQL statement text or parameters bound to precompiled SQL statements have an implicit storage class. Under circumstances described below, the database engine may convert values between numeric storage classes (INTEGER and REAL) and TEXT during query execution.
Много лет я вместе с этим говоном бок о бок был. Много крови он мне попил. К сожалению, я не мог выбирать СУБД. Если бы выбирал я, то это был бы либо MS SQL Express, либо Firebird, либо MySQL (т.е. MariaDB). Не связывайся с ним.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Nuzhny, Вы писали:
N>Да, я и имею ввиду: и там, и там написать в лоб. Вариант с C# будет быстрее? Или надо одинаково заниматься оптимизацией?
Я когда-то баловался олимпиадными задачками на митапе, там можно было любой язык применить. Чел решил задачку на плюсах и она даже уложилась по времени, а я решил её же на питоне с numpy и время выполнения в разы меньше, чем у плюсника вышло.
Re[11]: Неуверенные в своей востребованности на рынке труда,
Здравствуйте, Артём, Вы писали:
Аё>...Чел решил задачку на плюсах..., а я решил её же на питоне с numpy...
А зачем сравнивать производительность разных программ? Ты бы ещё скорость экскаватора со скоростью седана сравнил.
Я тут невдно Firebird вспоминал — ***дцать лет назад работал с ним, ещё с версией 1.5. Смотрел, живой ли он ещё и что поменялось.
Вот, смотри: Firebird и PostgreSQL формально решают одну задачу, но это разные программы. Они работают с разной скоростью на разных запросах. Почему бы какой-то оди не оставить!? А вот нет...
Всё сказанное выше — личное мнение, если не указано обратное.
Re[12]: Неуверенные в своей востребованности на рынке труда,
Здравствуйте, Философ, Вы писали:
Аё>>...Чел решил задачку на плюсах..., а я решил её же на питоне с numpy...
Ф>А зачем сравнивать производительность разных программ? Ты бы ещё скорость экскаватора со скоростью седана сравнил.
Это не разные программы. Это разные решения для одной и той же задачи, от разных участников хакафона.
Re[13]: Неуверенные в своей востребованности на рынке труда,
Здравствуйте, Философ, Вы писали: N>>Я SQL не использую, но всё равно интересно. Что, прямо таки можно написать запрос на SQL и на C# и второй вариант будет ощутимо быстрее? Ф>Для случая такого упоротого говна как SQLite это теоретически возможно. Для остальных СУБД — сомнительно.
Мне кажется, вы ответили на какой-то другой вопрос.
Основная разница между linq (который подразумевался под "написанием запросов на С#") и обычным порошком — в объёме кода.
В какой-то момент объём кода на "обычном порошке" становится настолько велик, что на него забивают, и упрощают себе задачу.
Например, ленятся сделать проекцию там, где нужна проекция — и тащат в память лишние данные.
Или, например, ленятся добавить доп.условие фильтра и фильтруют уже в памяти.
Или, например, ленятся сделать разные тексты запроса для разных комбинаций параметров, и СУБД приходится выбирать неудачный план запроса.
Linq позволяет все эти штуки делать лёгким движением руки, без многостраничного бойлерплейта. Это и приводит к тому, что приложение на его основе порождает более удачные запросы.
А что там внутри СУБД — это дело СУБД. Если СУБД — хорошая (а не SQLite), то она может воспользоваться более качественно подготовленным запросом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Неуверенные в своей востребованности на рынке труда,
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Артём, Вы писали:
Аё>>Это не разные программы. Это разные решения для одной и той же задачи, от разных участников хакафона.
Ф>Разные решения одной задачи приводят к разному коду и разному быстродействию. Язык здесь сбоку. Ф>Разный код формирует разные программы.
Он эту прохладную историю уже выносил на публику года четыре назад. Там выигрыш в скорости у Python-а образовался за счет того, что Тёмчик вызвал из Python-а готовую функцию, написанную на Си, тогда как в решении на C++ человек все делал с нуля сам.
Re[4]: Неуверенные в своей востребованности на рынке труда, при
Здравствуйте, tapatoon, Вы писали:
T>Ох уж мне эти async/await... Как там, повезли нормальный дебаг для них?
+100500
T>В реальном мире приходилось разгребать баги в компоненте, где всё в этих async-ах.
IMHO — логированием в лог-файл — только так.
T>Мопед был не мой, но больше было некому. Это жесть. И производительность была ниже плинтуса. В итоге я сделал вывод — чтобы эффективно использовать async/await нужно обладать квалификацией, позволяющей написать свой шедулер
Возможно.
Re[4]: Неуверенные в своей востребованности на рынке труда, при
Здравствуйте, sergii.p, Вы писали:
Аё>>Я перешёл с плюсов на чистую жаву на x3 больше в 2011г. Если представится возможность перейти на x2 больше на плюсы- с радостью перейду .
SP>в 11-ом было реально перейти. Сам это делал. А сейчас, языки настолько далеко ушли, что без знания 11+14+17+20 на С++ не вернёшься. Как минимум на x3. Любой интервьювер будет рассматривать тебя на собесе после такого перерыва как джуна.
Здравствуйте, Артём, Вы писали:
S>>выигрыш в скорости у Python-а образовался за счет того, что Тёмчик вызвал из Python-а готовую функцию
Аё>Да, всё так. Посыл "C++ нужен там, где нужно быстродействие" в общем случае неверен.
Наверное поэтому та самая функция и не была написана на Python-е.
Re[5]: Неуверенные в своей востребованности на рынке труда, при
Здравствуйте, so5team, Вы писали:
S>А он, кстати говоря, уже обломался в 2016-м году с попыткой устроится на C++ разработчика: https://rsdn.org/forum/job/7261174
Здравствуйте, Артём, Вы писали:
S>>Наверное поэтому та самая функция и не была написана на Python-е. Аё>Решение задачи было написано на Python-е.
Тёмчик, ты вряд ли поймешь, но для читателей этой темы проведу аналогию: когда мне нужно подсчитать в скольких файлах подключается <array>, то я напишу конвейер:
grep "#include <array>" -l -r include/*.h | wc -l
и это будет работать, скорее всего, гораздо быстрее, чем написанная в лоб программа на С++, делающая тоже самое.
Но скорость работы в этом конвейере обеспечивается вовсе не bash-ем.
