crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> Буфер для обмена между классами
Sokoloff
  опции профиля:
сообщение 16.4.2009, 19:32
Сообщение #1


Участник
**

Группа: Участник
Сообщений: 237
Регистрация: 1.4.2009
Из: Москва
Пользователь №: 654

Спасибо сказали: 50 раз(а)




Репутация:   11  


Вот подскажите как лучше сделать.

Есть 2 класса один генерит постскрипт, и передает его во второй класс, которй рендерит этот ps с помощью ghostscript.
Вопрос в том, как лучше передавать постскрипт, что использовать в качестве буфера.

Варианты QString и QByteArray я сразу отверг, т.к постскрипт в первом классе генериться по частям (отельно заголовок, отдельно тело и.т.д.) и общий размер я заранее не знаю, а перевыделять память при каждом добавлении IMHO это не хорошо.

Вариант с QStringList вроде очевиден, класс специально создан для хранения больших текстовых данны. Но, внутри у него QString, т.е. используется UTF16, а postscript это ASCII, ghostscript тоже принимает char*, соответственно имеем лишний расход памяти, и ненужное преобразование ASCII->UTF16->ASCII. Не аккуратненько как-то.

Можно использовать QList<QByteArray>, вроде никаких проблем, но не так очевидно как с QStringList.

Еще есть вариант (и он, даже, практически готов), это не использовать буфер вообще, а внутри первого класса, а для каждого кусочка постскрипта вызывать метод фторого класса и передавать в него этот кусок. Но что-то мне кажеться что это лишнее усложнение логики.

Вот поскажите как лучше сделать, что использовать в качестве буфера, или это все мелочи и я просто парю себе мозг?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 16.4.2009, 19:36
Сообщение #2


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9669
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


ну не знаю толком что у тебя и как, рас уж вопрос возник, то навеное есть тому причина.

В качестве промежуточного хранилища могу ещё назвать QTemporaryFile, кажется так называется
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Sokoloff
  опции профиля:
сообщение 16.4.2009, 19:56
Сообщение #3


Участник
**

Группа: Участник
Сообщений: 237
Регистрация: 1.4.2009
Из: Москва
Пользователь №: 654

Спасибо сказали: 50 раз(а)




Репутация:   11  


Цитата(Litkevich Yuriy @ 16.4.2009, 20:36) *
ну не знаю толком что у тебя и как, рас уж вопрос возник, то навеное есть тому причина.

В качестве промежуточного хранилища могу ещё назвать QTemporaryFile, кажется так называется


Да нет, никаких особых причин нет, оптимизацией я пока еще не занимался, хотя и особых тормозов не видно. Это "по молодости и от излишнего усердия"©, т.е. маловато опыта и перфекционизм терзает:)
Ладно по другому задам вопрос, есть в QT какой-то стандартный/распространенный метод передачи большого блока (до 1 мегабайта) не юникодного текста.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
SABROG
  опции профиля:
сообщение 16.4.2009, 21:52
Сообщение #4


Профессионал
*****

Группа: Участник
Сообщений: 1207
Регистрация: 8.12.2008
Из: Russia, Moscow
Пользователь №: 446

Спасибо сказали: 229 раз(а)




Репутация:   34  


Цитата(Sokoloff @ 16.4.2009, 20:56) *
(до 1 мегабайта)

Сначала хотел предложить QTextStream и файл, но раз заранее известно, что максимум 1Мб, то скорее всего такие варианты:
QBuffer
QByteArray - сразу выставить размер в 1Mb (это смешно по современным меркам, когда firefox кушает 200-300Мб). Далее append()
QList<QLatin1String> - позволит избавится от насильной перекодировки в unicode. QStringList - синоним QList<QString>. Удобно добавлять через оператор <<
static unsigned char array[1048576] = {0} - стандартный байтовый массив и Си строки.

P.S.: если скорость критична, то я бы попробовал все варианты и сравнил. Но как правильно кто-то сказал "преждевременная оптимизация - в большенстве случаев лишняя трата времени, которое могло бы уйти на что-то более полезное".
Например сегодня я наткнулся на такую статью про Qt - http://www.kdedevelopers.org/node/3663. Если вкратце, то человек замерил скорость заполнения/стирания области (rect) и написал свой алгоритм, который делает это быстрее чем Qt. В итоге, когда я прогнал эти тесты на Qt 4.5, то практически все они показали одинаковые результаты, т.е. тролли уже оптимизировали.

Сообщение отредактировал SABROG - 16.4.2009, 22:01
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Sokoloff
  опции профиля:
сообщение 16.4.2009, 23:05
Сообщение #5


Участник
**

Группа: Участник
Сообщений: 237
Регистрация: 1.4.2009
Из: Москва
Пользователь №: 654

Спасибо сказали: 50 раз(а)




Репутация:   11  


Цитата(SABROG @ 16.4.2009, 22:52) *
Цитата(Sokoloff @ 16.4.2009, 20:56) *
(до 1 мегабайта)

Сначала хотел предложить QTextStream и файл, но раз заранее известно, что максимум 1Мб, то скорее всего такие варианты:
QBuffer
QByteArray - сразу выставить размер в 1Mb (это смешно по современным меркам, когда firefox кушает 200-300Мб). Далее append()
QList<QLatin1String> - позволит избавится от насильной перекодировки в unicode. QStringList - синоним QList<QString>. Удобно добавлять через оператор <<
static unsigned char array[1048576] = {0} - стандартный байтовый массив и Си строки.

P.S.: если скорость критична, то я бы попробовал все варианты и сравнил. Но как правильно кто-то сказал "преждевременная оптимизация - в большенстве случаев лишняя трата времени, которое могло бы уйти на что-то более полезное".
Например сегодня я наткнулся на такую статью про Qt - http://www.kdedevelopers.org/node/3663. Если вкратце, то человек замерил скорость заполнения/стирания области (rect) и написал свой алгоритм, который делает это быстрее чем Qt. В итоге, когда я прогнал эти тесты на Qt 4.5, то практически все они показали одинаковые результаты, т.е. тролли уже оптимизировали.


В том-то и дело, что я не знаю размер буфера, это будет зависеть от того, какой postscript попадется, один мегабайт, это я так примерный-максимальный размер указал, а так, кто знает какого размера будет одна страница постскрипта.
Я чего пристаю. Теоретически я понимаю, что при добавлении к QByteArray данных, будет выделяться новый блок памяти суммарного размера и копироваться данные, что не оптимально, но это в теории. Но на практике полно ситуаций когда оптимальность приносится в жертву простоте, вот и спрашиваю, как на на практике замарачиваются с такими вещами или не забивают себе голову?
Опять же, использование функции QByteArray::reserve дает "better performance" а вот насколько better?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
LE0N
  опции профиля:
сообщение 17.4.2009, 7:59
Сообщение #6


Студент
*

Группа: Участник
Сообщений: 97
Регистрация: 10.3.2009
Из: Беларусь
Пользователь №: 604

Спасибо сказали: 0 раз(а)




Репутация:   0  


Мне вот чего не понятно. Почему ты так боишься динамического распределения памяти? Не умеешь с ней работать?
Если есть данные переменной длины, то здесь два варианта:
1) Динамическое распределение
2) Выделение МАКСИМАЛЬНОГО количества памяти.
----------
Чего ты ждёшь от форумчан?
И что значит "я не знаю длины этих данных" ? То, что данные имеют переменную длину, и её узнать можно во время выполнения? Или то, что ты вообще не знаешь их количество и не можешь определить его даже во время выполнения программы?
ЗЫ. Копирование данных в оперативной памяти занимает минимум времени. А если ещё и динамическое распределение умное написать, так вообще огонь будет...

Сообщение отредактировал LE0N - 17.4.2009, 8:03
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 17.4.2009, 9:37
Сообщение #7


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9669
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Sokoloff, если уж есть опасения в большом кол-ве данных, то я бы использовал временный файл. Помоему вполне удобная штука.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
igor_bogomolov
  опции профиля:
сообщение 17.4.2009, 10:11
Сообщение #8


Профессионал
*****

Группа: Сомодератор
Сообщений: 1215
Регистрация: 22.3.2009
Из: Саратов
Пользователь №: 630

Спасибо сказали: 235 раз(а)




Репутация:   29  


Стратегии увеличения размера
Sokoloff, возможно вы уже это читали, если нет, то будет очень интересно.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
SABROG
  опции профиля:
сообщение 17.4.2009, 10:32
Сообщение #9


Профессионал
*****

Группа: Участник
Сообщений: 1207
Регистрация: 8.12.2008
Из: Russia, Moscow
Пользователь №: 446

Спасибо сказали: 229 раз(а)




Репутация:   34  


Я для работы писал программу еще 2 года назад и мы её используем. Но я писал её тогда еще на Borland Builder C++. Тогда мне казалось, что для данных выкаченных с SQL сервера мне хватит 1Гб памяти. Со временем количество данных расло и дорасло до 5Гб, т.е. уже полезло в своп и программа начала падать с out of memory. В итоге перешел на ifstream/ofstream. Сначала данные записываю во временный файл (в поток), а потом его читаю (из потока). В результате скорость работы программы несколько упала, но зато позволила делать работу.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Sokoloff
  опции профиля:
сообщение 17.4.2009, 12:14
Сообщение #10


Участник
**

Группа: Участник
Сообщений: 237
Регистрация: 1.4.2009
Из: Москва
Пользователь №: 654

Спасибо сказали: 50 раз(а)




Репутация:   11  


Гигабайтов быть не может, это все-таки рендер постскрипта.
Временный файл, имеет смысл использовать для хранения данных, получили данные, сохранили в файл и некоторое время их используем. У меня же, хранения нет: нажали на кнопку, прочитали одну или несколько PS страниц, обработали, передали в рендер, и временный файл здесь IMHO лишний.
Всем спасибо за ответы, решил остановиться на QBuffer, и не забивать себе голову.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 29.3.2024, 10:13