| 1.1, iPony (?), 08:44, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Какой-то велосипед.
Время с точностью до 0.00001 секунды - это круто
| | |
| |
| 2.2, pkdr (ok), 08:57, 10/10/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
 С каких это пор для компьютеров интервалы времени в 0.01 миллисекунду стали чем-то мелким и не заслуживающим измерения? Даже в начале 90-х время работы процессов всегда мерялось в долях миллисекунды, а иногда и в микросекундах.
| | |
| |
| 3.40, soarin (ok), 17:36, 10/10/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
 Ты метрологическую проверку сделал, что автор программы измеряет что надо?
Пользователю это не надо, и QElapsedTimer не даёт гарантированную точность на полных разрядах своего типа данных.
К чему твоё высказывание?
| | |
| |
| 4.52, Аноним (-), 21:25, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Может всё-таки "поверка"?
Пора бы уже заметить и усвоить эту разницу в одну букву.
| | |
|
| 3.41, Аноним (-), 17:52, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
У обычных писюков 10 микросекунд могут работать а могут и нет. Это как минимум требует таймер высокого разрешения (>=100 kHz).
| | |
| 3.60, Онаним (?), 05:10, 11/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
А какая вообще разница сколько там миллисекунд затрачено на очистку этого файла, особенно если ты делаешь это вручную через GUI?
| | |
|
| |
| 3.4, Crazy Alex (ok), 09:41, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Вот в миллисекундах и мерять. Там флуктуации доступа к диску или особенности шедулера больше повлияют, чем эти доли.
| | |
| |
| 4.14, RazrFalcon (ok), 11:31, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Можно и без дробной части, да. Это не принципиально. Просто есть файлы которые обрабатываются меньше чем за 1мс.
| | |
|
| |
| |
| 5.44, Аноним (-), 18:53, 10/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Это философский вопрос. Особой нужды нет.
Ответ на него давно дал Кнут, сказавший что преждевременная оптимизация - корень всех зол.
| | |
| |
| 6.54, Ordu (ok), 22:55, 10/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Да, совершенно верно. И поэтому автор svgcleaner пишет на опеннете новости о своей программе, а Аноним перечитавший Кнута изображает иксперда в комментах к этой новости.
Во-первых, не надо путать оптимизацию, и диагностику производительности.
Во-вторых, дай себе труд повтыкать вот сюда: https://gist.github.com/hellerbarde/2843375
Ты видишь, что среди разных рассмотренных временных отрезков младшие пять _порядков_ на глаз неразличимы? То есть, при определённых условиях, можно, совершив какую-нибудь глупость, сделать свою программу раз в сто тормознее и даже не заметить этого. Двадцать лет назад, и тем более до этого, такой проблемы не было, потому что "программа в сто раз медленнее" -- это было практически наверняка заметно глазом. Сегодня программист накручивает одну сложность на другую сложность, на третью, на десятую, программа начинает выполняться уже не "моментально", а всего лишь "в мгновение ока". Программу отправляют на "боевую задачу", где объёмы выполняемой работы на пару порядков больше, и выясняется что программа говно. И оптимизировать её уже невозможно, потому что там накрученных сложностей и алгоритмических глупостей больше, чем собственно кода.
И я попрошу заметить ещё один факт: Кнут писал TAOCP, работая на столь древних и тормозных компьютерах, которые ни тебе, ни даже мне не пришлось застать. И на тех компьютерах оптимизация становилась своевременной и даже необходимой после первой же глупости, типа выбора списка с простыми инсёртами, вместо массива с простым рандом-акцессом.
| | |
|
|
| 4.42, Аноним (-), 17:53, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Для оптимизации процесса. Для опеннетчиков же это философские вопросы и поводы покудахтать.
| | |
|
|
|
| 1.6, ГеккоШтат (?), 09:55, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Допустим:
1.есть 10 тыс файлов.
2.Их надо пройти этим софтом.
Зная среднее время можно хоть примерно сказать сколько времени необходимо на все 10 тыс.
Не?
| | |
| |
| |
| |
| |
| 5.61, alltiptop (ok), 08:49, 11/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 >>>основная работа идёт построчная
> Никакой работы со строками тут нет.
А как он тогда работает с xml(svg)?
| | |
|
|
|
|
| 1.8, Аноним (-), 10:20, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
О, для Rust уже есть Qt-биндинг.
>Консольная версия переписана с C++ на Rust.
Ну это поспешили, в GCC ещё нет фронтенда для Rust.
| | |
| |
| |
| 3.45, Аноним (-), 18:55, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> И это прекрасно.
Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не пойти на дно вместе с их стремной экосистемой и такими аффтарами.
| | |
| |
| 4.65, Аноним (-), 11:20, 11/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> И это прекрасно.
> Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не
> пойти на дно вместе с их стремной экосистемой и такими аффтарами.
Можно подумать, анонима заставляют платить за пользование программой -- и таким образом хотят развести на бабло. А компилятор с экосистемой закрытая проприетарь и сразу сломается.
Уважаемый форточник (или маковод), вы кое-что путаете -- это совсем не то, к чему вы так привыкли!
| | |
|
|
|
| 1.9, Kaffeine (?), 11:07, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– | |
Хорошая программа, с её помощью в KDE оптимизировали иконки Breeze, размер уменьшился с 28,0 до 9,4 мегабайт.
Непонятно только, зачем понадобилось переписывать на (гораздо менее популярный и, как уже сказали, ещё отсутствующий в GCC) Rust. Автор хочет сказать, что ускорение в три раза получилось сменой языка, а не модернизацией алгоритма? Прошу ответить конструктивно. :)
| | |
| |
| 2.16, RazrFalcon (ok), 11:34, 10/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Они использовали svgo, насколько я знаю. И то, у них там от силы половина файлов обработана. svgcleaner позволяет еще в 2 раза сжать.
| | |
| |
| |
| 4.57, RazrFalcon (ok), 01:30, 11/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Те иконки, что лежат у них в репе, можно сжать в два раза. Если они и прогоняют их через svgo, то на очень слабых настройках.
| | |
|
|
| 2.18, RazrFalcon (ok), 11:39, 10/10/2016 [^] [^^] [^^^] [ответить]
| +6 +/– | |
Увеличение производительности связано исключительно с алгоритмами. Rust даже немного медленнее плюсов.
Но так как это личный проект - пишу на том, на чём удобно. А это Rust. От плюсов слишком много боли.
| | |
| |
| 3.68, ваноним (?), 19:12, 12/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
боль лишь у неосиляторов стандарта и у мазохистов с кривыми компиляторами
| | |
|
| 2.23, тоже Аноним (ok), 12:41, 10/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Не знаю, как у автора, а у меня бывало, что переписывание нетривиального алгоритма с C-like оптимизированной версии на обычные STL-контейнеры заметно ускорило алгоритм просто потому, что автор стал лучше понимать, что конкретно происходит в процессе ;)
Здесь же стоит учесть, что SVG - это, в сущности, XML. Если разбирать (а потом писать) его своим велосипедом на "крестах", может здорово просесть производительность по сравнению со стандартной, оптимизированной по скорости библиотекой высокоуровневого языка. Впрочем, никто не мешает подобрать аналогичную библиотеку и для "крестов"...
| | |
| |
| 3.31, Гвидо (?), 14:06, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Не знаю, как у автора, а у меня бывало ... что автор стал лучше понимать...
Как это понимать?
| | |
| |
| 4.48, тоже Аноним (ok), 19:44, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Может быть, после второго-третьего прочтения?
Ничего сложного вроде бы не написано и довольно очевидно, что в первом случае имеется в виду автор обсуждаемой программы, а во втором - автор вышеупомянутого алгоритма.
Использование одного и того же слова сломало парсинг? Сочувствую...
| | |
| |
| 5.67, Гвидо (?), 20:19, 11/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ты напрасно называешь себя автором алгоритма - у тебя не то что не отросли навыки алгоритмического мышления, но и отсутствует культура написания вменяемого кода.
Именование переменных, понимание их области видимости - всё это в лучшем случае у тебя впереди.
Дерзай.
| | |
|
|
|
| |
| 3.26, RazrFalcon (ok), 13:13, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Программа однопоточная. GUI просто запускает несколько копий параллельно. Но увеличение производительности именно в консольной версии, которая однопоточная.
| | |
|
|
| 1.10, Аноним (-), 11:08, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Столбец Ratio странный. Либо там должно быть отношение размеров стало/было, либо он должен называться «Удалено». Тогда будет понятно. А сейчас не понятно.
| | |
| |
| |
| 3.13, Аноним (-), 11:31, 10/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Я вижу. Но проценты вычисляются так: (1 - стало/было) * 100. Не совсем Ratio, правда? Это число показывает сколько процентов байт было удалено.
| | |
|
| 2.17, RazrFalcon (ok), 11:37, 10/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Столбец показывает сколько было удалено. С терминологией, возможно, неувязка.
| | |
|
| 1.19, Аноним (-), 11:47, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А для видеофайлов такое есть? В информации о файлах, озданных мной, всегда libavcodec 57
| | |
| 1.20, Аноним (-), 11:52, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> Степень очистки снижена на ~5%, ценой стабильности и корректности;
Какой из следующих вариантов означает эта фраза?
чистить стало хуже, зато стабильнее и корректнее
чистить стало лучше, зато менее стабильно и корректно
чистить стало хуже, зато менее стабильно и корректно
| | |
| 1.28, Александр (??), 13:37, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"теперь работают в режиме без потерь качества (lossless)" - значит ранее описанную словом линию (векторная графика ведь) изгибали или уничтожали? Или этот тег писали через букву?
| | |
| |
| 2.33, RazrFalcon (ok), 15:02, 10/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Суть в том, что раньше программа содержала деструктивные опции, которые удаляли/искажали видимые части изображения. Теперь их нет.
| | |
|
| |
| 2.46, Аноним (-), 18:57, 10/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Мда. Я думал что у GCC в C++ плохие сообщения об ошибках. Признаю, был неправ!
| | |
|
| 1.47, Аноним (-), 19:28, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Пропустил через svgcleaner файл сделанный в Inkscape.
Исходный файл: 42мб, имеет много слоёв с векторами и битмапами, многие слои временно выключены.
Файл на выходе: 10мб, информация о слоях удалена, невидимые элементы удалены.
Впечатления:
- gui-версия из Downloads не запускается "...could not find or load the Qt platform plugin "xcb""
- консольная версия работает
- считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
- эдакий "Flatten Image" for publishing svg-files
| | |
| |
| 2.49, тоже Аноним (ok), 19:51, 10/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> - считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
Вообще-то когда говорится о потере качества в векторной графике - обычно имеется в виду огрубление линий путем уменьшения количества узлов и упрощение эффектов - например, их растеризацией. В данном случае ни того, ни другого не происходит, качество картинки не теряется - так что имеет место тот самый заявленный lossless reduce.
Теряется дополнительная информация - так это и является заявленным функционалом программы! Она и предназначена для постпродакшена, а не для рабочих файлов. Ну, и полей для откровенно ненужной информации в этом формате не предусмотрено ;)
| | |
| 2.59, RazrFalcon (ok), 01:42, 11/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>>информация о слоях удалена
В SVG нет понятия Слой. Inkscape просто создаёт группу, которую svgcleaner с легкостью удаляет, ибо она не имеет смысла. "Отключенные слои" - это просто <g display="none">, вот я его и удаляю.
Вы можете отключить: Ungroup groups и Remove invisible elements, что бы оставить "слои".
>>считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
В README чётко описано зачем нужна прога: "The main purpose of the svgcleaner is to losslessly reduce size of an SVG image, created in a vector editing application, before publishing.". То есть чистить "рабочий" файл смысла нет.
| | |
|
| 1.63, Xenia Joness (ok), 09:42, 11/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > Консольная версия переписана с C++ на Rust.
> Существенное увеличение производительности (до трёх раз быстрее)
Отсюда следует вывод, что Rust быстрее C++ в 3 раза. Это вправду так?
| | |
|
