AkelPad

Posted: **Thu Mar 15, 2012 11:55 am**

VladSh

В плаге используются иконки, как-то "красный крестик" и т.п., если они вшиты в плаг, а не подтягиваются, можно ли сделать так, чтобы они были доступны извне, как и те 2 иконки, которые там уже есть?

Красный крестик и треугольник с воскл. знаком подтягиваются из user32.dll.

Вопрос по размеру плага. Размер плага Coder.dll = 208.4kb (это понятно, т.к. там реально наворот), а FileInfo.dll = 201.7, можно ли что-то с этим сделать? Не критично, но всё же.. хотелось бы чтобы плаг весил как-то пропорционально другим.

Уффффф... Во-первых, непонятно, какой в этом смысл (на дискету не влезает?

), во-вторых, все опции и так заточены под уменьшение размера. Почему такой большой - очень просто. В Сях чуть ли не на каждый чих приходится изобретать свой велосипед, в Дельфях же большинство нужных функций реализовано в стандартных модулях. Но поскольку эти модули довольно обширны, естественно, что присутствует небольшой % не используемого кода. Но ради никому не нужной экономии 10-20 килобайт реализовывать все используемые системные функции самому нет ну совершенно никакого желания. Максимум, что можно уменьшить, - это за счет одной из иконок, сейчас она засовывается хз откуда и зачем.

Кстати о размерах: Paint в Windows 7 весит 6.36 мб

Posted: **Thu Mar 15, 2012 2:01 pm**

Fr0sT
Ясно, я думал, что в WinAPI всё есть, и просто дёргается оттуда

Posted: **Thu Mar 15, 2012 2:15 pm**

В WinAPI только функции по работе с Windows (сюрприз, правда?

), а всякие преобразования типов, строковые операции и прочее - забота каждого отдельного языка.

Version 0.5
* Билд под x64! НЕ ПРОВЕРЕН (ну нет у меня поблизости x64 системы)
* Главный файл проекта теперь предназначен для Delphi XE2 (проект для Delphi 2010 также доступен как FileInfoD2010.dproj)
* Лишняя иконка удалена (баг Delphi 2010)
* Убрана двухпиксельная полоска слева от дочернего диалога в табе

Posted: **Thu Mar 15, 2012 3:05 pm**

В Сях чуть ли не на каждый чих приходится изобретать свой велосипед

Бугага. Продемонстрируй пример велосипедостроения. С-шники хоть могут работать без libc. А паскалисты не могут себе отрезать uses System;

Posted: **Thu Mar 15, 2012 3:43 pm**

FeyFre

Продемонстрируй пример велосипедостроения

сложи две произвольные строки.

паскалисты не могут себе отрезать uses System

На самом деле можно, даже без особых ухищрений (правка юнита и перекомпиляция). KOL-овики этим промышляют.

Posted: **Thu Mar 15, 2012 4:03 pm**

Fr0sT, это было предложение тебе:

Posted: **Fri Mar 16, 2012 6:09 am**

FeyFre
нет ничего лучше, чем самому ответить на свой же вопрос

Вот пожалуйста, о чем я и говорил. Причем у тебя еще ограничение - итоговая строка не может быть больше 100 символов.
Так что сравни:

Code: Select all

// foo = "foo", bar = "bar"
1) char *foobar;

2) foobar = malloc(
3)   strlen(foo) + 1 /* ! тут еще непонятно что ставить в случае произвольной добавки между foo и bar */ + 
4)   strlen(bar));

5) strcat(
6)   strcat(
7)     strcpy(foobar, foo),"-"), bar);

и

Code: Select all

// foo = 'foo', bar = 'bar'
1) var foobar: string;
2) foobar := foo + bar

И это я еще опускаю проверки на успешность выделения памяти, плюс подкапотные пробежки с проверкой на нулевой символ, коих будет как минимум три в действиях 5-7 (тогда как в Паскале длина известна изначально, что позволяет сразу шуровать целый блок памяти).

Posted: **Fri Mar 16, 2012 9:38 am**

Fr0sT, А теперь откомпилируйте в EXE свой вариант(с той же функциональностью) и скажите его размер(и таблицу импорта). У меня это 2.5Кб(+5 символов импорта)

Posted: **Fri Mar 16, 2012 10:39 am**

Fr0sT, а если по теме. Экономия байт очень даже нужна. Во-первых, плагин на 700Кб никому не нужен отожрет много места в PlugsPack что в свою очередь выливается в тормоза обновления. Мой релиз SpellCheck v приблизительно 1 занимал очень много места(КБ
Во-вторых, у нас всё-таки работа с данными, и чем больше свободной памяти, тем лучше.
В-третьих, экономия места - одна сторона, вторая - быстродействие. Мы на С большинство задач можем сделать экономнее на порядки, и с точки зрения памяти, и с точки зрения шустроватости. Например, мне в Templates одну большую строку нужно разбить на две штуки. На паскале Вы бы это делали методом копирования. Мне достаточно поменять 2-байта. Таким образом я получил профит:
1. Сэкономил время на копирование
2. Не увеличил отпечаток памяти в два раза, за счет того что у меня одновременно выделена память для оригинал и копии.
3. Не выполнял системных вызовов в Менеджер памяти, таким образом сэкономив кучу времени.
4. Также благодаря тому что не обращался к Менеджеру памяти за кусками, я не ухудшал фрагментацию кучи, чем сэкономил ресурсы всем кто пользуется кучей.
Как обойти всё это на паскале я понятия не имею, и так подозреваю если не невозможно, то очень геморно, и результирующий код нечитаемый.

Posted: **Fri Mar 16, 2012 12:33 pm**

FeyFre

А теперь откомпилируйте в EXE свой вариант(с той же функциональностью) и скажите его размер(и таблицу импорта). У меня это 2.5Кб(+5 символов импорта)

Замечательно. У меня это

Code: Select all

program Project1;

procedure OutputDebugString(lpOutputString: PWideChar); stdcall; external 'kernel32.dll' name 'OutputDebugStringW';

begin
  OutputDebugString('foo' + 'bar');
end.

= 3 значащих строки и 20.992 байт. Я потратил на написание кода две минуты с нуля. А сколько потрачено в твоём варианте (2.5 Кб, 17 значащих строк)?
Также давай прикинем, на сколько времени мой вариант будет закачиваться дольше на модемной скорости: 4.4 секунды. Кого это волнует?
Нельзя также забывать, что мой вариант без увеличения размера умеет куда больше, чем твой обгрызенный, куда на каждый чих придется добавлять кучу экспортов. Однако как proof of concept можно взять урезанные системные модули, которые дадут порядка 5 КБ (можно почитать тут).
Так что пусть Дельфи и не самый минималистичный, но разрыв с Си не так уж и велик в абсолютных единицах. А кто высчитывает лишние байты - тот пусть пишет на асме.
Если же говорить не про синтетические проекты из серии "интересная фигулина", а про реальные вещи, то Сишные проги тоже жиреют с наращиванием функционала.
Я тоже не дурак поглядеть на размер, намекнуть на bloatware-ность и поругать жирные фреймворки, но до фанатизма-то доходить не надо.

Во-первых, плагин на 700Кб никому не нужен отожрет много места в PlugsPack что в свою очередь выливается в тормоза обновления.

Если он будет делать что-то полезное, то вот лично мне абсолютно похрен, сколько он занимает (в разумных пределах, конечно). И уверен, большинству народа тоже похрен. Прогресс, хвала Небесам, несется вперед как в зад ужаленный, гигагерцы с гигабайтами и гигабитами доступны даже нигерийцу, так что микроминиатюризация кода отходит в разряд умозрительных задач. Ну и для всяческих встроенных слабеньких девайсов.

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

...сказал человек, с вероятностью 90% располагающий >2 Гб RAM и с вероятностью 60% - ОСью, которая занимает 1 Гб RAM и 10 Гб на диске.

Мы на С большинство задач можем сделать экономнее на порядки, и с точки зрения памяти, и с точки зрения шустроватости. Например, мне в Templates одну большую строку нужно разбить на две штуки. На паскале Вы бы это делали методом копирования. Мне достаточно поменять 2-байта.
...
Как обойти всё это на паскале я понятия не имею, и так подозреваю если не невозможно, то очень геморно, и результирующий код нечитаемый.

Всё, что можно сделать на С, можно сделать и на Дельфях, причем с практически тем же быстродействием.
А вот обратное - неверно. Достаточно взять строку размером мегов этак 100 и вычислить ее длину.

Задачу о разбиении строк в Дельфях можно решить абсолютно тем же макаром - вставкой нулей в место разрыва. Но можем и проверить, если дашь точную формулировку задачи.
Что же касается 3 и 4, то даже при разбиении копированием это с большой долей вероятности неверно, т.к. у встроенного менеджера памяти своя куча, заранее откушенная у системы, и мелкие копошения в ней никак не затрагивают системную кучу.

Posted: **Fri Mar 16, 2012 2:29 pm**

сказал человек, с вероятностью 90% располагающий >2 Гб RAM и с вероятностью 60% - ОСью, которая занимает 1 Гб RAM и 10 Гб на диске.

Человек располагает ровно 2Гб - 512Мб(на видео адаптер) памяти, и ОСью занимающей <1Гб на диске(гадеюсь это понятно что ~80% содержимого папки винды не есть частью ОСи), а на РАМ плевать, мы в юзерспейсе.

Я потратил на написание кода две минуты с нуля.

Те же две минуты. (Мне не нужно гуглить или ещё где искать прототипы часто используемых функций, тем более если уточнение типа не важно, только размеры и количества). Большая часть времени уходит на собственно набор, ну и на обфускацию.

куда на каждый чих придется добавлять кучу экспортов

Ту кучу экспортов можно заменить одним #include - эффект будет тот же, но демонстрационность пропадает.

Я тоже не дурак поглядеть на размер, намекнуть на bloatware-ность и поругать жирные фреймворки, но до фанатизма-то доходить не надо.

Ну дык и я не на ассемблере предложил всё делать.Там бы весь образ вместился бы в 512 байт.

Posted: **Fri Mar 16, 2012 2:54 pm**

Народ, ну не надо меряться размерами мобильных телефонов.
Следующий код на C++

Code: Select all

#include <string>

int main()
{
  std::string s = "abc";
  s += "def";
  return 0;
}

тоже собирается отнюдь не в несколькокилобайтовую программу, особенно если к тому же собирать с помощью g++.

Posted: **Fri Mar 16, 2012 4:22 pm**

DV, ну за C++ мы не говорим. Точнее за STL. Конечно и там можно минимизировать использование избыточного кода, но для этого нужно хорошо это STL знать и хотя бы иногда пользоваться им непокнижному. Не говорю уже об implementation defined.

Posted: **Fri Mar 16, 2012 4:54 pm**

FeyFre wrote:за C++ мы не говорим. Точнее за STL.

А почему? По моему, это как раз тот баланс..

Posted: **Fri Mar 16, 2012 5:30 pm**

VladSh, я может быть отстал от жизни по поводу паскаля и дельфи, потому ответе мне: когда там появились шаблоны, раз Вы так смело равняете дельфи к STL?

AkelPad

FileInfo plugin