stdout буферизуется, stderr не буферизуется

тоесть можно с помощью writeln (который через stdout работает) писать что-то, программа упадёт и ты не увидешь последних строк

Просто мне нужно понять оно у меня скорость обработки снизит если будет потоком на экран все выводить или нет. Время обработки ответа от БД 7 миллисекунд

а зачем тебе всё выводить на экран?

если время обработки важно

да пока хз... можно по идее и не выводить, но пока так децл нагляднее

короче если важна скорость, то лучше не надо

лучше в файл куда-нибудь, а в идеале вообще не выводить)

это да

что работа с консолью, что работа с файлами, все это очень медленно)

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

Просто лог у меня может содержать миллионы записей... в файл писать все это тоже как бы смысла нет. В консоли я думал оно просто будет "уходить вникуда" или как оно там устроено. Короче хвост будет тереться

пиши в файл а из файла делай tail -f

ну файл на десяток GB мне тоже не нужен...

Выделить пару МБ в памяти и писать перезаписывая туда? И обернуть весь код в try-catch и если что-то пошло не так то записать в файл хвост?

тогда не пиши никуда ничего :)

Задача непонятна твоя

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

ты сначала определись с "не помешал бы"

Что конкретно не помешает и для каких целей

В файлах на десяток гигов нету ничего страшного

В файлах на десяток гигов нету ничего страшного

но и полезного тоже не много)

если мы про логи

Я грепал по таким файлам временами )

Было бы нормальное ГУИ было бы наверно проще. Я бы хоть глазами видел какой блок кода исполняется. Мол: сейчас значения находятся вне указанных координат.

просто в консоли непонятно как это выводить. т.е. ничего не делать — непонятно что сейчас происходит. В файл писать тоже не очень

а на сколько правильно сравнивать строки "aa" == "aa"? или лучше через equal?

а на сколько правильно сравнивать строки "aa" == "aa"? или лучше через equal?

смотря что в строках вроде

в плане?

на самом деле вроде нет разницы

equal работает с range любыми

а == только массивы можно сравнить

или как-то так вроде

М... а тут ему что не нравится?

ой туплю

все

Кстати, а как на языках типа PHP и того же Python обрабатывают большие данные? Там же это как-то делают? Просто у меня после всех казалось бы оптимизаций после нескольких часов работы приложение на Ди работающее с БД упало с аут-оф-мемори.

на PHP никак практически)

но вообще, конечно, вне зависимости от языка секрет в контроле памяти)

А на Python же обрабатывают?

там берется штатный язык или какие-то дополнительный обвески используются?

с питоном у меня как-то не заладилось, по этому поводу сказать ничего не могу)

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

Я вот не знаю. Мы с Олегом долго пытались разобраться почему у меня приложение получающие из БД данные ело память и падало на 32 битной сборке. В итоге грешить осталось только на драйвер mysql т.к. узких мест в приложении не осталось. Там 20 строчек буквально было. Автор драйвера сказал, что вероятно проблема в компиляторе. Типа в 32 версиси ГК как-то криво обрабаывает указатели и все дела. В итоге 64-битная сборка действительно начала не только потреблять в 2 раза меньше памяти, но и освобождать ее. Оставил процесс работать на ночь. Утром проверил — оно упало с аут-оф-мемори через пару часов работы.

а питон тут при чем?

Вот мне и интересено как дела в других языках обстоят. Много ли там с этим проблем

дампы по 9 гигов анализировал на python

На 32 битной версии?

нет

оперативы было 1 гб если речь об этом

Т.е. никаких проблем не было вообще?

вообще

от слова "совсем"

Я не пытаюсь сказать что D хуже Python. Но чтоб понять происходит утечка памяти, придется воспользоваться memory profiler.

А как профайлить когда обработка может часами идти? Просто я с большими данными никогда не работал.

взять меньше данных

дык на меньших вроде отрабатывает

ну это не значит, что там память не бежит

просто ее хватает

Вообще это хорошая идея сделать файл globals.d В нем объявить логер следующим образом: FileLogger fLogger; static this() { fLogger = new FileLogger("ProcessingLog.txt"); } и потом сделать import globals; и дальше просто в коде вызывать: log("bla-bla-bla") ? Или как-то более правильно можно?

Чтобы так делать надо пользовать sharedLog переменную

Её можно переопределить

а мой варинат чем плох?

Тем что другой код не будет через твою переменную логировать

ERROR: S client not available

другой это какой? Тот в котором FileLogger fLogger не будет доступен?

Кстати о питоне, там все библиотеки обработки написаны на C

По сути питон просто дёргает функции

другой это какой? Тот в котором FileLogger fLogger не будет доступен?

Нет, который не твой

Который об этой переменной знать не может

так, а разве то что я написал не равно тому что ты написал? переменная не импортируется == код не знает о этой переменной

Переменная sharedLog объявлена в std, через нее проходит всё логирование

А как профайлить когда обработка может часами идти? Просто я с большими данными никогда не работал.

Создай себе виртуалку маленькую и там профилируй

Олег, блин, перечитал несколько раз. Я никак в толк не возьму. Ну вот если у меня FileLogger fLogger если он виден, то мой логгер же будет значение от него записывать в переменную которая в нем определена

Вообще с gc профайлинг на утечку так себе затея

Вообще с gc профайлинг на утечку так себе затея

Если именно о всех библиотеках, то Вы не правы. Как минимум django не на С. Если речь о стандартных либах, то да, там много написано на C. И действительно много и сторонних либ на С там написаны. Например scipy, pycuda, pillow. Но это не значит, что от этого он стал хуже.

Вообще с gc профайлинг на утечку так себе затея

Как искать утечки тогда?

Если именно о всех библиотеках, то Вы не правы. Как минимум django не на С. Если речь о стандартных либах, то да, там много написано на C. И действительно много и сторонних либ на С там написаны. Например scipy, pycuda, pillow. Но это не значит, что от этого он стал хуже.

как я понимаю ответ не на то сообщение) Дмитрий спросил об обработке больших данных, там, можно сказать, всё на С

Как искать утечки тогда?

я сам, честно говоря, не понял

я пробовал valgrind и он показывал ООЧЕНЬ много утечек

а это просто память, контролируемая gc

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

я пробовал valgrind и он показывал ООЧЕНЬ много утечек

да, мне тоже такое показывал.

но что-то вроде есть

как я понимаю ответ не на то сообщение) Дмитрий спросил об обработке больших данных, там, можно сказать, всё на С

да, прошу прощения, пропустил слово "обработки". Однако обрабатывал дамп на чистом python. Читал gzip построчно и проблем не было с памятью

да, прошу прощения, пропустил слово "обработки". Однако обрабатывал дамп на чистом python. Читал gzip построчно и проблем не было с памятью

это довольно медленно

чистый питон

да, прошу прощения, пропустил слово "обработки". Однако обрабатывал дамп на чистом python. Читал gzip построчно и проблем не было с памятью

Библиотеки были, но с обработкой не были связаны

это довольно медленно

Да, было медленно, но не было out-of-memory) Скорость обработки не была принципиальна, если интересно.

кстати о профилировании. Что-то все-таки есть https://wiki.dlang.org/Development_tools#Heap_profiling

У меня обработка очень тупорная. Взять трек из БД (порядка 400 тыс записей в каждом). И все эти 400k отправить в другую БД которая проводит с данными некоторые манипцляции, получить ответ. т.е. пока больше ничего не считается. Короче перезапустил все еще раз сократив количество треков (до этого у меня из-за ошибки они по два раза обрабатывались).

Кстати, как я поинимаю в подобном сценарии никакая многопоточность мне не нужна? Или какую-то выгоду может дать?

кстати о профилировании. Что-то все-таки есть https://wiki.dlang.org/Development_tools#Heap_profiling

dub build --build=profile-gc немного не то, это профайлинг именно gc и он не затрагивает код на С или прямые вызовы malloc

Кстати, как я поинимаю в подобном сценарии никакая многопоточность мне не нужна? Или какую-то выгоду может дать?

Как вариант, если размер данных известен (400к, например), можешь разбить данные на куски по 100к и параллельно в четырех потоках обрабатывать их)

ну или извратиться совсем, для развлечения, в одном потоке 4 штуки fiber сделать, и после обработки каждой записи делать yield()

Не, у меня по 200-300-400К много данных. В каждом треке примерно столько (треков несколько тысяч) Просто я не пойму. на сколько многопоточность сможет дать плюс в данном случае.

имхо ни сколько