А вот сдесь вы абсолютно неправы и сравнение ваше в корне неверно. Деление на модули подразумевает как раз что один модуль может использовать другой модуль для выполнения каких то операций если они(операции в нем реализованы), а не дублировать уже имеющийся функционал. Тоесть уже созданный функционал одного модуля может многократно использоваться в других. В общем деление на модули это намного более абстрактная вешь чем разрезание окорока на части. С десь более подходит сровнение с использованием в машиностроение  стандартных крепежных элементов, тоесть если вы имеети болт диаметром столько то с шагом резбы столько то в одной конструкции и он у вас по какимто причинам испортился то вы можете сходить в магазин и сказать мне вот такой и такой то болт нужен, и выпушеный совершенно другой компанией этот болт встанет на место как родной. В программирование это называется API. Не забывайте что программирование это инженерная дисциплина. И сдесь сильна унификация. Иоесть зачем мне разрабатывать новое если здесь будет прекрасно работать старое.

Не совсем.

Мы тут вчера подумали, и решили... что модуль распознавания речи, а также блондинок и брюнеток в видеорядах - если он написан на чистом PHP - может иметь такие размеры...

По теме:

Сокращение имени переменных конечно поможет выиграть килобайты, а в вашем случае может и мегабайты... НО! Дело в том что исходный ведь код РНР не передаёться клиенту!!! Он не качает ваши длинные переменные! Их обрабатывает только РНР интерпритатор! Поетому это всё ГОН если вы думаете, что намного быстрее скрипт заработает с переменными обладающими коротким наименованием. Это бред. Спасибо.

Добавлено через 1 минуту и 23 секунды
На паскале напишите прогу которая парсит тхт файл, удаляет закоментаринные строчки и пустые строки и всё...

Добавлено через 1 минуту и 57 секунд
Или на РНР и напишите... он в парсинге силён...

 он не за скорость исполнения беспокоился, а за объём трафика при перекидывании и метраж доступный на сервере

Интересно, для какого (даже халявного) сервера критичны скрипты на 11 мб, при том,что эти скрипты будут работать с графикой, которая, наверняка, будет храниться по соседству?

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



вообще 11 мегов скрипта на галлерею предполагает раздутость остального кода

Всё равно ГОН. Клиенту пойдёт только HTML. Если у него 12 метров вычислений (И вправду размер улыбает) то беспокоиться за трафик не стоит. За место может и стоит. Мне кажеться что у автора весь сайт весит 12 метров...  12 метров текста - это извините меня художественное произвидение уже.    

знаешь, у меня дома 10кБ/с скорость, это значит заливать через фтп в лучшем случае придётся 20 минут. а если несколько раз? я б заманался

bars80080, советую пользоваться архиваторами   
Целые сайты в архиве заливаются одним файлом, что через FTP в сто раз быстрее, чем заливать каждый скрипт по отдельности и сводит вероятность раъединения соединения к минимум. А потом остаётся пустяковое дело - разархивировать это всё. Разархивация, как правило, выполняется практически мгновенно, даже если сайт состоит из сотни скриптов.

И набор скриптов на 10 мб будут занимать в архиве не более 100 кб. Зальются за 10 сек   

Это сообщение отредактировал(а) HackMan - 5.8.2008, 09:33

да? а можна поподробней, ибо gzip у меня точна не работает, как там реализовать процедуру?



хотя я кстати, скрипты метрами не загоняю, а вот jpg, что архивируй, что не архивируй...

Про jpg речь не идёт. Тут грозились, что 12 мб - это чисто кода    Да и как ни крути - 1 архив на 100 метров зальётся в разы быстрее, чем 100 картинок по метру.


Ну кроме gzip существуют ещё bzip и zip, как минимум   
Как вариант - вот

У меня есть скрипт (точнее 2 файла), реализованный на php, который разархивирует обычный zip-архив. Если интересно - могу скинуть в PM

Это сообщение отредактировал(а) HackMan - 5.8.2008, 10:18