Gnuplot: загрузка данных через stdin

Сам протестировал на файле данных в 5M (9.6с против 1.5с) - разница во времени исполнения чуть более чем в 6 раз. Наверно из-за более навороченного парсера.

В моей исследовательской системе управление манипулирование внешними файлами ни к чему, поэтому хочется обойтись потоками. Через stdin передаётся скрипт для gnuplot, а для данных надо будет задействовать внешний fifo, я правильно понимаю? Но вот fifo - это получше, но тоже внешний файл, есть ещё решения?

А не проще будет взять какую-нибудь библиотеку для работы с Гнуплотом, чем генерировать скрипты, а потом кормить их через stdin?

А разве библиотека для работы с Гнуплотом будет работать как-то иначе?

Да я пользовался библиотекой - она делает лишний на мой взгляд файл с данными. Я её хочу улучшить.

Вряд ли. Те, которые я знаю,работают либо через pipe, либо через fifo, либо через временный файл. Просто в них это уже реализовано :)

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

Попробовал схему gnuplot-код по stdio, данные для графика по fifo. Так вот если в окошке график крутить, то он при этом процессе постоянно виснет - каждый раз ему нужно скидывать одни и те же данные по fifo.

Это получается он настолько оптимизирован?

Да ну, бред какой. Как минимум там можно было «заинлайнить» данные в переменную и выкинуть второй fifo. Как максимум — должно и так быстро крутить. Хотя судя по

разница во времени исполнения чуть более чем в 6 раз

у тебя какой-то неправильный гнуплот и графики он строит не те и не так.

Нашёл только какую-то опцию «Double buffer» но только для оффтопика. А так при просматривании графика на экране гнуплот каждый раз будет запрашивать данные и парсить их перед перерисовкой.

Твой гнуплот ведёт себя по-другому?

Да. «при просматривании графика на экране гнуплот каждый раз будет запрашивать данные и парсить их перед перерисовкой» — лично твоя фишка.

$ ls -l test-pipe 
prw-r--r-- 1 redarch19 users 0 июн 30 12:51 test-pipe
$ cat plot.gpl


set terminal wxt font "Sans,9"  persist enhanced size 640 ,480

unset logscale x 
unset logscale y 

# set title 
set xlabel "x"
set ylabel "y"
set grid

set format y "%g"
set format x "%g"
plot "<cat test-pipe" using 1:2 with lines lw 1.0 linecolor 1 title ""
$ cat plot.gpl|gnuplot &

Гнуплот запущен, ждёт данных у fifo. Теперь о данных:

$ cat data.dat

Здесь например. Подаём данные:

$ cat data.dat > test-pipe

Теперь вот в если в окне ты скроллишь график, масштабируешь твоему гнуплоту опять подавать данные не надо?

Вообще с гнуплотом можно согласиться когда по скрипту надо отрендерить 100500 файлов в растре, то лучше поступаемые данные фильтровать чтобы только нарисовать а не держать ещё один массив данных в памяти.

А если не хочется грузить навороченные графические библиотеки или более тяжёлый matplotlib и лучше запускать отдельный, более лёгкий, процесс гнуплота, чтобы, крутя данные в нём, можно было расчёты контролировать. Он легче matplotlib'а, покрывает все требуемые функции, а главное - удобнее. В этом случае при разных отображениях одних и тех же данных каждый раз парсить эти данные ИМХО глупо.

plot "<cat test-pipe" using 1:2 with lines lw 1.0 linecolor 1 title ""

Сейчас не могу проверить, но ты не упоролся? Вот так че делает?

plot "test-pipe" using 1:2 with lines lw 1.0 linecolor 1 title ""

У меня это не помогает, всё равно требует данные.

Теперь вот в если в окне ты скроллишь график, масштабируешь твоему гнуплоту опять подавать данные не надо?

все-таки надо:

If you use ’-’ with replot, you may need to enter the data more than once. See replot (p. 103), refresh (p. 103).

одна надежда на

The second mechanism defines a named data block as a here-document. The named data is persistent and may be referred to by more than one plot command.

но как минимум понадобится «инлайнящий» скрипт.