тот кто это написал минимум ламер... может такие монстры как KDE и OpenOficce загружаются медленно, но в силу своей внутреней громозкости а никак не в силу того что они написны на C++.

Почиатайте статью, прежде чем так утверждать; возможно, как раз, что ламер ты.

А ещё лучше см. http://lwn.net/2001/0802/devel.php3

Да, новость ламерская, а ссылка - оччень даже интересная!
ELF был всегда громоздким форматом, но зато без проблем с shared библиотеками.
Кстати, у BSD a.out этих проблем не было, но весь мир пошёл менее эффективным (IMHO!!!!) путём :)))))))))))))

Для тех, кто так и не вкурил

A note posted to the KDE Development list has proposed a method for preprocessing C++ object files before linking in order to improve performance during program startup. "Waldo Bastian's document demonstrates that the current g++ implementation generates lots of expensive run-time relocations. This translates into the slow startup of large C++ applications (KDE, StarOffice, etc.). The [proposed] program "objprelink.c" is designed to reduce the problem. Expect startup times 30-50% faster. "

Red Hat's Jakub Jelinek also posted another C++ prelinking solution that is worth looking at. (Thanks to Anthony Green)

Господа, прежде чем делать выводы, научились бы сначала разобраться в чём дело и почитать статьи. А то как то даже обидно получается.

"научились бы сначала разобраться в чём дело и почитать статьи" - может сначала по русски разговаривать научишся?

Chuchelo, ты точно чучело. Как раз таки C++
проги грузятся медленно, так как С++. Почитай
статью. Ламер ты.

Последний анонимус: Ламероы не пишут проги, которыми каждый линуксойд пользуется. Качественные, профессиональные проги.

Лучшим способом ускорения KDE является убийство X Window System. Period. Гном тормозит ни чуть не меньше, хоть и написан на C.

Bluesman

Ты когда, где и как сравнивал, проницательный ты наш?!

2 Bluesman: пред[яви ссылки на результаты подробного профайлинга сначала, идиот.

2 speer: Вы будете отрицать? Хотя, честно говоря, совсем уж последних гномов и КДЕ не пробовал. Надо будет поставить глянуть. Не думаю, что они стали быстрее.

Bluesman

> 2  speer: Вы будете отрицать? Хотя, честно говоря, совсем уж последних
> гномов  и КДЕ не пробовал. Надо будет поставить глянуть. Не думаю, что
> они стали быстрее.
Баран, тебе вопрос задали - как тебе открылось, что именно из-за X KDE тормозит?
Не переводи на тему "а разве вы будете отрицать?" - так бабки на скамейке трепятся.
2 speer: сорри за встревание.

Все нормально, Блузмен под XP гонял, поэтому такие результаты.

Насчет тормознутости - чисто субъективные ощущения (RAM 256M), KDE2 пауза на инициализации весьма заметна, потом уже как-то и ничего, а вот гном быстрее и что забавно, скорость запуска почти не меняется при снижении RAM до 64М. Пока JBuilder не засвопит, разница малоощутима.

А если РАБОТАТЬ надо - так никто WindowMaker не отменял ;)) Так что, почему KDE из-за Xов тормозит - не понятно.

2speer (*) (2001-08-05 17:50:24.0):

> Так что, почему KDE из-за Xов тормозит не понятно.
Ну, это старая история -- Блюзман как-то вычитал про "слоновость"
Xов, и с тех пор везде об этом говорит. Своего мнения у него нет,
и спорить с ним -- по меньшей мере глупо.

> Лучшим способом ускорения KDE является убийство X Window System. Period. Гном тормозит ни чуть не
> меньше, хоть и написан на C.

> Bluesman

Слушай, тебе еще не надоело? У тебя есть СВОЕ мнение. В силу особенности характера ты
считаешь его единственно верным. Иногда ты бываешь прав, иногда порешь чушь (как в
этот раз, например).

Одно несомненно. Ржавление твоих мозгов прогрессирует -- еще год назад ты
хоть как - то аргументировал свои высказывания. Теперь у тебя осталось только
слепое почитание авторитетов от M$

2 anonymous (*) (2001-08-05 20:48:32.0): Да нет, года 3 у меня второй винчестер (который выкинуть было жалко) занимал Linux разных версий и контор. Поэтому знаю я о тормознутости иксов (а также KDE, GNOME, Mozilla и всех остальных слонов) не понаслышке. Хотя, как я говорил, совсем уж последних версий я не видел и допускаю, что они стали на полпроцента быстрее (хотя и сильно сомневаюсь в этом, за исключением Мозиллы). Ну а если на гном водрузить Nautilus, чтобы можно было сравнить его с КДЕ, то тормоза вообще становятся удручающими.

Bluesman

2 anonymous (*) (2001-08-05 21:02:00.0): BTW, где в моем постинге слово MS? И где вы такую забойную траву берете?

Bluesman

2Голубой! Тебе уже сказали, есть факты - давай. Нет - засунь свое мнение себе... куда больше нравиться... на то ты и голубой!

2Bluesman: "Не думаю...[skip]"
А здря... Иногда полезно.
---
WBR, Сиваков Константин.

Программы, написанные на C++, очень часто содержат виртуальные функции :-). Объяснять, что такое позднее связывание, думаю, никому не надо. Дело в том, что в библиотеке QT, и, следовательно, в KDE, очень широко используется техника наследования. Как и у всего в этом мире, у наследования есть две стороны: хорошая и не очень. Первая излагается в учебниках по UML. Вторая проявляется в жизни. Дело в том, что позднее связывание занимает время, и происходит при старте программы перед запуском main. Если количество виртуальных функций исчисляется десятками или сотнями - это ерунда. Но когда их десятки тысяч, как в случае kdelibs - это уже долго. KDE частично решила эту проблему с помощью демона KDEINIT. Но ускорение связывания в C++ - это просто круто... :-)

Хорошая новость!

2 anonymous (*) (2001-08-06 07:24:19.0)
Первый толковый анонимус :)
ЗЫ. а сама новость дюже радует :)

> Дело в том, что позднее
> связывание занимает время, и происходит при старте программы перед
> запуском main.

Позднее связывание действительно занимает время, но
происходит это не при старте программы!
Иначе эту работу мог бы выполнить компилятор.
Например:
pBase->virtual_f ();
где pBase -- указатель на базовый класс с виртуальной функцией
virtual_f
Эта конструкция может вызывать абсолютно разные функции в
зависимости от того, куда указывает pBase и для этого нужно
копаться в таблице виртуальных функций и именно в процессе
выполнения программы.

Поэтому мне кажется, что дело в чём-то другом.

>и для этого нужно
>копаться в таблице виртуальных функций и именно в процессе
>выполнения программы.

Зачем копаться-то?

Указатель на таблицу устанавливается в конструкторе (компилятором).

А при вызове нужно всего лишь взять указатель на метод.
Вроде не так уж много операций.

эхх не верят мне... наверное не пишут на C++ совсем...

Насколько я понял из исходной статьи, речь идет о тормозах, которые на запуске вносит динамический линкер. По личному опыту могу подтвердить, что да - когда в WINE из громадной winelib сделали набор в несколько десятков мелких .so, скорость запуска упала в _разы_. Может, на гигагерцном проце это и не особо заметно, а на медленной машине чувствуется буквально нутром ;-)

Понял в чём дело.

Время уходит на заполнение виртуальных таблиц
при линковке.

2chuchelo (*) (2001-08-06 12:43:45.0)

>эхх не верят мне... наверное не пишут на C++ совсем...

Странно верить твоему голословному заявлниею.

Авторы статей привели примеры и результаты тестов.
Не уподобляйся Bluesman-у

Все rules но как поставить ?

последний аноним, просто есть много прог быстро запускающихся написанных на C++, и это заставляет задуматься :-)

>Лучшим способом ускорения KDE является убийство X Window System. Period.

Очень мудрая мысль. Подписываюсь. Только вывод из нее делаю диаметрально противоположный - поскольку X Window уже доказала свою применимость и совместимость с идеологией Unix, убивать надо KDE. Ибо, как говорили в 1985-1991 годах, горбатого могила исправит. И гнома туда же, ибо столь же горбат.

Невозможно написать винды лучше чем M$ или Apple. Поэтому, не следует пытаться воспроизвести винды над Unix-ядром. Надо искать другой путь создания удобной для пользователя среды.

2chuchelo
>просто есть много прог быстро запускающихся написанных на C++
это типа:
-------
#include <iostream>
int main()
{
std::cout << "Hello, world!\n";
return 0;
}
-------
?

Bluesman в одном прав: GNOME говно полное и место ему на помойке
а не на десктопе. X-ы тут не при чем. Вообще америкозы программы
ни х#я писать не умеют.

2chuchelo:

а не знает ли многоуважаемый, где можно надыбать англицкую версию WebDownloader for X? ;) а то у меня в русской та-а-а-кая ... ну в общем понятно что c интерface`ом ..

с уважением theCrow

а зачем ее дыбать? :-) установите локаль в C и все будет окей. export LC_ALL=C думаю поможет

2bluesman>
> Да нет, года 3 у меня второй винчестер (который выкинуть было
> жалко) занимал Linux разных версий и контор. Поэтому знаю я о
> тормознутости иксов (а также KDE, GNOME, Mozilla и всех остальных
> слонов) не понаслышке.

И своп у тебя тоже на этот винт был? Небось винт шустрый ;-))
А Иксы-то не тормозят.

И почему то третий Quake вышел под Linux ровно на неделю раньше чем
под Win32? Это к слову о тормознутости Иксов.

с яРЮПСЯРПСОЮ Б ЙМХФЙЕ СЯЕ ПЮЯЯЙЮГЮМН - ЙЮЙ Х ОНВЕЛС РНПГЛХР ++ МЮ ДХМЮЛХВЕЯЙНИ КХМЙНБЙЕ(Х Б БХМДЮУ РНФЕ) - Ъ ВХРЮК МН СФЕ ГЮАШК, ВН-РН РЮЛ ОПН ЩЙЯОНПР ЙКЮЯЯНБ.

Вот таки не надо про тормознутость X11 гнать. Да, XFree86 тормоз по сравнению с коммерческими реализациями, но чтобы эта тормознутость проявилась, надо очень сильно постараться. 2D оно лихо рисует, особенно если писать с умом. Ну а эти студенческие поделки - гном, KDE, тормозилла - так и будут тормозить, и от X11 это совершенно не зависит.

btw, на хрена тебе Nautilus? Файловые менеджеры - дерьмо и должны сдохнуть.

C++ - rulez!

> Bluesman в одном прав: GNOME говно полное и место ему на помойке > а не на десктопе. X-ы тут не при чем. Вообще америкозы программы > ни х#я писать не умеют.

И гному и KDE место на помойке. Но дело тут не в умении писать программы, а в идеях заложеных при проектировании. Складывается ощущение, что никаких идей там нет вообще.

Торможение крупных программ

А кто-нибудь вообще задумывался, почему тормозят большие программы?
Большая часть времени уходит на запуск конструкторов всех глобальных обектов. Так, ради интереса, можно посмотреть на то, что выводит тот же всем известный фотошоп ри старте. Он при запуске подгружает и инициализирует все, что только можно.
Единственный путь от этого избавиться - писать так, чтобы объект реально инициализировался только тогда, когда он реально нужен.
Кроме этого - есть объекты, которые используются сразу несколькими программамми, о чем тоже стоит вспоминать и учитывать это.
Использование плагинов, если подгружать их только по мере надобности, тоже может очень сильно увеличить скорость работы программы.

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

2 mithraen: Фотошоп загружает несколько дллок без которых не может обойтись, а потом сканирует плагины на предмет обнаружения новых. Только и всего. К тому же написан он вроде как на C.

Bluesman

Плохое проектирование - давить. Вместе с фотожопой.

>Фотошоп загружает несколько дллок без которых не может обойтись,

Можно конкретнее? Без каких dll'ек не может работать фотошоп, когда я его только запустил (и кроме UI ничего нет)? Все остальное можно загружать в отдельной нити по мере необходимости.

>а потом сканирует плагины на предмет обнаружения новых.

На это нужны доли секунды. И опять же - не нужно это на этапе запуска программы. При входе в меню с плагинами это делать надо.

>Только и всего. К тому же написан он вроде как на C.

В C++ просто эта проблема проявляется более остро.

тормозат не сами по себо программы на С++ а вызова виртуальных функций для которых подобный прелинк должен был бы присутствовать изначально на уровне программы ld - но в мире много странностей и халтуры

тормозат не сами по себо программы на С++ а вызова виртуальных функций для которых подобный прелинк должен был бы присутствовать изначально на уровне программы ld - но в мире много странностей и халтуры

тормозат не сами по себо программы на С++ а вызова виртуальных функций для которых подобный прелинк должен был бы присутствовать изначально на уровне программы ld - но в мире много странностей и халтуры

>С++ а вызова виртуальных функций для которых

Когда С++ начал учить ?

> тормозат не сами по себо программы на С++ а вызова виртуальных
> функций для которых подобный прелинк должен был бы присутствовать
> изначально на уровне программы ld - но в мире много странностей и
> халтуры

C++ тормозит больше всего именно из-за особенностей стиля программирования на нем, с учетом того, что программист ленив по определению. При запуске C++ программы вызываются конструкторы всех глобальных объектов, которых в крупном проекте много, и в которых много вложеных объектов, а программист, по своей натуре существо ленивое, всю инициализацию делает в конструкторе.