Отчего у linux такие особенности?
dll будучи раз загруженной в памяти там и остаётся, shared library нужно каждый раз подгружать для каждого приложения
эээ, да ладно, что, правда так уж в разы? и так уж медленно менюшки работают? Что-то не сталкивался...
dll будучи раз загруженной в памяти там и остаётся, shared library нужно каждый раз подгружать для каждого приложения
но для первого запуска это тоже справедливо
причём для статически собранных приложений, для которых подгружаться ничего не должно - opera, например (здесь разница раза в 3 на моём компе)
3) из-за архитектурных особенностей x11 ?
каких, например?
у меня - в разы 
Сравни время запуска Acrobat Reader, Opera, Firefox.
А менюшки протестируй на Gimp, Eclipse (GTK psi, sim (qt).
Сравни время запуска Acrobat Reader, Opera, Firefox.А менюшки протестируй на Gimp, Eclipse (GTK psi, sim (qt).
Сдаётся мне, что это особенности не линукса вообще, а твоего конкретного случая. У меня на работе gaim под XP, дома gaim под убунтой - единственная разница, которую я ощущаю - это наличие у виндового gaim глюка с тултипами. Других приложений на qt или gtk у меня в винде нет, так что всю выборку проверить не могу.
Возможно, у тебя слабое железо и прожорливый оконный менеджер, типа гномового metacity?
Возможно, у тебя слабое железо и прожорливый оконный менеджер, типа гномового metacity?
у меня кде
железо слабое - Celeron 1.7, но на менюшки и кнопочки этого должно хватать
а акробата у тебя тоже нет?:)
железо слабое - Celeron 1.7, но на менюшки и кнопочки этого должно хватать
а акробата у тебя тоже нет?:)
Памяти сколько?
хотя я, наверное, не прав
2) Loading of shared libraries is cached by the Linux kernel. Only the first
application that needs a certain library needs to actually load the library
from disk. Subsequent processes that need the library will make use of the same
copy that already resides in memory.
This is further optimized by the fact that the Linux kernel only loads parts of
the library (on a page by page basis) when these parts are actually used.
а я где-то читал что библиотеки только по наследству передаются если они перемещаемые.
может у тебя просто иксы не настроены и всё через vesa работает?
Shared objects in Linux usually contain PIC which avoid the need to relocate the library at load time. All code pages can be shared amongst all processes using the same library and can be paged to/from the file system. In x86, there is no simple way to address data relative to the current location since all jumps and calls are instruction-pointer relative. Hence, all references to the static globals were directed through a table known as Global Offset Table (GOT).
вообще, интересно стало почитать
http://www.securityfocus.com/infocus/1872
http://www.securityfocus.com/infocus/1873
256. своп не используется
настроен вроде
xorg.conf:
22 Section "Module"
23 Load "dbe"
24 Load "extmod"
25 # Load "fbdevhw"
26 Load "glx"
27 Load "record"
28 Load "freetype"
29 Load "type1"
30 # Load "xtt"
31 Load "randr"
32 # Load "dri"
33 EndSection
....
87 Section "Device"
88 Identifier "Videocard0"
89 Driver "nvidia"
90 VendorName "Videocard vendor"
91 BoardName "GeForce4 MX440"
92 Option "NoLogo" "yes"
93 Option "RandRRotation" "on"
94 # Option "Rotate" "CCW"
95 Option "AGPFastWrite" "yes"
96 Option "NvAgp" "1"
97 Option "RenderAccel" "true"
98 Option "AllowDDCCI" "true"
99 EndSection
xorg.conf:
22 Section "Module"
23 Load "dbe"
24 Load "extmod"
25 # Load "fbdevhw"
26 Load "glx"
27 Load "record"
28 Load "freetype"
29 Load "type1"
30 # Load "xtt"
31 Load "randr"
32 # Load "dri"
33 EndSection
....
87 Section "Device"
88 Identifier "Videocard0"
89 Driver "nvidia"
90 VendorName "Videocard vendor"
91 BoardName "GeForce4 MX440"
92 Option "NoLogo" "yes"
93 Option "RandRRotation" "on"
94 # Option "Rotate" "CCW"
95 Option "AGPFastWrite" "yes"
96 Option "NvAgp" "1"
97 Option "RenderAccel" "true"
98 Option "AllowDDCCI" "true"
99 EndSection
акробата у меня нет в линуксе
меня evince устраивает 
а меня kpdf, хотя evince тоже неплох =)
у меня FF и там и там запускается долго, Акробат 7.0 на Убунте запускается быстрее чем в венде, хотя когда юзал сусю, то там запускался медленее, Опера запускается одинаково быстро. А вот что всё медленно рисуется, это да, я из-за этого даже Xgl поставил - стало менее противно, хотя меня бесит её, Xgl-ная, дефолтная тема.
256. своп не используется
Ну вообщем этого маловато
к томе если еще и своп выключен
ты попробуй на xp своп отключить и сравни.....
> Ну вообщем этого маловато
Не важно. Человек сравнивает Linux и Windows на одном и том же железе.
Не важно. Человек сравнивает Linux и Windows на одном и том же железе.
ты попробуй на xp своп отключить и сравни...оно вообще выживет после такого? с 256 то...
+1
Постоянно наблюдаю такой же эффект. IMHO не зависит от характеристик железа, конкретных версий программ, ядра итп.
Наиболее сильно заметно на Acrobat Reader, OpenOffice, Firefox. Хотелось бы узнать в чем дело.
Постоянно наблюдаю такой же эффект. IMHO не зависит от характеристик железа, конкретных версий программ, ядра итп.
Наиболее сильно заметно на Acrobat Reader, OpenOffice, Firefox. Хотелось бы узнать в чем дело.
а ты уверен что это именно загрузка библиотек?
вокруг этих монстров может наворочена куча всякой ерунды.
да и баблиотеки они могут как-нить неестественно хитро загружать.
вокруг этих монстров может наворочена куча всякой ерунды.
да и баблиотеки они могут как-нить неестественно хитро загружать.
ну уж ты-то, как отец, мог бы посмотреть, на что тратится время =)
От темы графических элементов много зависит. Можно попробовать в gtk Raleigh она же Simple. Еще бывает полезно иконки почистить, слишком много statов делается если иконок много. Они вроде бы кэшируются, но толку от этого как всегда 0.
Вобщем много причин, начиная от планировщика ядра и драйвера видеокарты X-сервера и заканчивая двойным буфером при отрисовке. Так что сильно исправить ситуацию не получится.
Вобщем много причин, начиная от планировщика ядра и драйвера видеокарты X-сервера и заканчивая двойным буфером при отрисовке. Так что сильно исправить ситуацию не получится.
Наиболее сильно заметно на Acrobat Reader, OpenOffice, Firefox. Хотелось бы узнать в чем дело.Думаю, на оптимизацию этих приложений под Windows разработчики отдают больше сил, чем под другие системы.
а что, неужели у оупенофиса под виндой есть шансы против ms office? 
А то. Лицензионная политика больше нравится пользователям.
Он дешевле чуток )
В Винде графическая подсистема в ядре находится, а в Линуксе пока вся эта срань (многочисленные X библиотеки, оконные библиотеки и т.п.) загрузится-пропейджфолтится - время и пройдет. Хотя, это сильно не должно задержать.
Есть ещё одно полезное свойство кстати - плохая совместимость с вирусами для MS Office.
Неужели это настолько актуальная проблема?
+1 тормозов не замечал. У меня kde (gentoo) бегает заметно быстрее чем XP. ooffice правда тормозит и там и там Но я думал это исключительно его личная фича (то же и про огнелиса). В целом же - если иксы с win+gdi+ сравнивать первые имхо выигрывают. Вспоминаются всякие object-dock etc которые под виндами дико тормозят, а их аналоги в линуксе вовсе нет. В общем - не факт. Многое еще от дистра зависит. Вот я по приколу ставил 10 suse - так там вообще ВСЕ тормозит. Такое чувство что даже терминал безиксовый и тот лагает
Но я думал это исключительно его личная фича (то же и про огнелиса). В целом же - если иксы с win+gdi+ сравнивать первые имхо выигрывают. Вспоминаются всякие object-dock etc которые под виндами дико тормозят, а их аналоги в линуксе вовсе нет. В общем - не факт. Многое еще от дистра зависит. Вот я по приколу ставил 10 suse - так там вообще ВСЕ тормозит. Такое чувство что даже терминал безиксовый и тот лагает Понятия не имею. Я с этими вирусами не сталкивался, о чём ни капли не жалею.
> а ты уверен что это именно загрузка библиотек?
> вокруг этих монстров может наворочена куча всякой ерунды.
Имелось ввиду +1 к тому, что наблюдается сильное замедление работы некоторых приложений.
Почему так происходит, или связано ли это как-то с библиотеками — я не знаю.
Сейчас решил провести эксперимент. Запустил профайлер, 10-15 раз запустил-убил Firefox.
Все гонялось на: Athlon XP 2500+ (1833 MHz 1.5 Gb RAM, Debian Linux Etch, Linux 2.6.18, oprofile 0.9.2, X.Org 7.1, Firefox 1.5.0.7, OpenOffice 2.0.4rc2.
Показывает следующее:
по модулям:
по функциям:
Вобщем, не видно, чтобы ld.so особо тормозил. В данном случае тормозят скорее не библиотеки, а обработка каких-то Javascript-ов (интересно, каких?).
Провел аналогичный эксперимент с OpenOffice. К сожалению, пришлось только запускать-прибивать его, так как при открытии любого из попавшихся мне под руку трех файлов он падал в segfault.
по модулям:
по функциям
Да, похоже здесь прав, страшно тормозит линкер. Хм, интересно.
Измерялось только время запуска, скорость тыкания менюшек не измерялась — скорее всего там будут другие результаты. По субъективным ощущениям, Qt-приложения летают очень быстро, все GTK-based сильно тормозит.
К сожалению, у меня сейчас нет времени, чтобы проводить какие-то детальные измерения. Может кто займется?
> вокруг этих монстров может наворочена куча всякой ерунды.
Имелось ввиду +1 к тому, что наблюдается сильное замедление работы некоторых приложений.
Почему так происходит, или связано ли это как-то с библиотеками — я не знаю.
Сейчас решил провести эксперимент. Запустил профайлер, 10-15 раз запустил-убил Firefox.
Все гонялось на: Athlon XP 2500+ (1833 MHz 1.5 Gb RAM, Debian Linux Etch, Linux 2.6.18, oprofile 0.9.2, X.Org 7.1, Firefox 1.5.0.7, OpenOffice 2.0.4rc2.
Показывает следующее:
по модулям:
180823 24.9176 libmozjs.so
114023 15.7125 firefox-bin
90682 12.4961 libc-2.3.6.so
68888 9.4928 vmlinux
57251 7.8892 libxpcom_core.so
40054 5.5195 libfontconfig.so.1.1.0
24118 3.3235 ld-2.3.6.so
23652 3.2593 libfb.so
18208 2.5091 nvidia_drv.so
15998 2.2045 libnspr4.so
10902 1.5023 libqt-mt.so.3.3.6
9093 1.2530 libfreetype.so.6.3.10
7849 1.0816 libpthread-2.3.6.so
7453 1.0270 Xorg
7317 1.0083 libglib-2.0.so.0.1200.4
по функциям:
samples % image name app name symbol name
180823 24.9178 libmozjs.so libmozjs.so (no symbols)
114022 15.7125 firefox-bin firefox-bin (no symbols)
57251 7.8893 libxpcom_core.so libxpcom_core.so (no symbols)
40054 5.5195 libfontconfig.so.1.1.0 libfontconfig.so.1.1.0 (no symbols)
19309 2.6608 libfb.so libfb.so fbSolidFillmmx
17125 2.3599 libc-2.3.6.so libc-2.3.6.so _int_malloc
15998 2.2046 libnspr4.so libnspr4.so (no symbols)
15584 2.1475 ld-2.3.6.so ld-2.3.6.so do_lookup_x
11115 1.5317 nvidia_drv.so nvidia_drv.so _nv000810X
10902 1.5023 libqt-mt.so.3.3.6 libqt-mt.so.3.3.6 (no symbols)
9093 1.2530 libfreetype.so.6.3.10 libfreetype.so.6.3.10 (no symbols)
7590 1.0459 vmlinux vmlinux mmx_clear_page
7446 1.0261 Xorg Xorg (no symbols)
7352 1.0131 libc-2.3.6.so libc-2.3.6.so malloc_consolidate
7317 1.0083 libglib-2.0.so.0.1200.4 libglib-2.0.so.0.1200.4 (no symbols)
7251 0.9992 libc-2.3.6.so libc-2.3.6.so _int_realloc
6872 0.9470 libc-2.3.6.so libc-2.3.6.so _int_free
6310 0.8695 libgobject-2.0.so.0.1200.4 libgobject-2.0.so.0.1200.4 (no symbols)
5871 0.8090 ld-2.3.6.so ld-2.3.6.so strcmp
5650 0.7786 vmlinux vmlinux __copy_to_user_ll
5457 0.7520 libc-2.3.6.so libc-2.3.6.so memcpy
5393 0.7432 libc-2.3.6.so libc-2.3.6.so free
5202 0.7168 libc-2.3.6.so libc-2.3.6.so strcmp
5018 0.6915 nvidia nvidia (no symbols)
4724 0.6510 vmlinux vmlinux timer_interrupt
4318 0.5950 oprofiled oprofiled (no symbols)
Вобщем, не видно, чтобы ld.so особо тормозил. В данном случае тормозят скорее не библиотеки, а обработка каких-то Javascript-ов (интересно, каких?).
Провел аналогичный эксперимент с OpenOffice. К сожалению, пришлось только запускать-прибивать его, так как при открытии любого из попавшихся мне под руку трех файлов он падал в segfault.
по модулям:
165309 35.8303 ld-2.3.6.so
49784 10.7905 vmlinux
39837 8.6346 configmgr2.uno.so
39402 8.5403 libuno_sal.so.3
32531 7.0510 libc-2.3.6.so
13364 2.8966 libuno_cppu.so.3
9984 2.1640 libtl680li.so
9624 2.0860 libqt-mt.so.3.3.6
9153 1.9839 libvcl680li.so
8680 1.8814 Xorg
7038 1.5255 libuno_cppuhelpergcc3.so.3
6578 1.4258 nvidia_drv.so
4965 1.0761 libX11.so.6.2.0
4612 0.9996 libpthread-2.3.6.so
4505 0.9764 libfontconfig.so.1.1.0
4013 0.8698 libstore.so.3
3705 0.8030 nvidia
3142 0.6810 libsfx680li.so
3011 0.6526 soffice.bin
по функциям
samples % image name app name symbol name
85199 18.4670 ld-2.3.6.so ld-2.3.6.so do_lookup_x
67359 14.6002 ld-2.3.6.so ld-2.3.6.so strcmp
39837 8.6347 configmgr2.uno.so configmgr2.uno.so (no symbols)
39402 8.5405 libuno_sal.so.3 libuno_sal.so.3 (no symbols)
13364 2.8967 libuno_cppu.so.3 libuno_cppu.so.3 (no symbols)
9984 2.1641 libtl680li.so libtl680li.so (no symbols)
9624 2.0860 libqt-mt.so.3.3.6 libqt-mt.so.3.3.6 (no symbols)
9153 1.9839 libvcl680li.so libvcl680li.so (no symbols)
8670 1.8792 Xorg Xorg (no symbols)
7621 1.6519 libc-2.3.6.so libc-2.3.6.so _int_malloc
7038 1.5255 libuno_cppuhelpergcc3.so.3 libuno_cppuhelpergcc3.so.3 (no symbols)
4505 0.9765 libfontconfig.so.1.1.0 libfontconfig.so.1.1.0 (no symbols)
4440 0.9624 ld-2.3.6.so ld-2.3.6.so _dl_relocate_object
4013 0.8698 libstore.so.3 libstore.so.3 (no symbols)
3705 0.8031 nvidia nvidia (no symbols)
3572 0.7742 libc-2.3.6.so libc-2.3.6.so _int_free
3443 0.7463 vmlinux vmlinux timer_interrupt
3330 0.7218 ld-2.3.6.so ld-2.3.6.so _dl_elf_hash
3194 0.6923 libc-2.3.6.so libc-2.3.6.so malloc
3142 0.6810 libsfx680li.so libsfx680li.so (no symbols)
3009 0.6522 soffice.bin soffice.bin (no symbols)
Да, похоже здесь прав, страшно тормозит линкер. Хм, интересно.
Измерялось только время запуска, скорость тыкания менюшек не измерялась — скорее всего там будут другие результаты. По субъективным ощущениям, Qt-приложения летают очень быстро, все GTK-based сильно тормозит.
К сожалению, у меня сейчас нет времени, чтобы проводить какие-то детальные измерения. Может кто займется?
По субъективным ощущениям, Qt-приложения летают очень быстро, все GTK-based сильно тормозит.+1, тоже замечаю такое
И не ты один.
При поиске удобных фронтэндов, там где это возможно, всегда ищу QT-based приложения.
При поиске удобных фронтэндов, там где это возможно, всегда ищу QT-based приложения.
В данном случае тормозят скорее не библиотеки, а обработка каких-то Javascript-ов (интересно, каких?).там всё основано на XUL а там js используется в качестве одного из движков.
всякие там плюгины и пол интерфеса на этом работают.
У меня ХР год отлично жила на 112МБ оперативной памяти + 168 свопа (его уменьшить не получалось при этом бОльшую часть времени общая загрузка памяти была около 130-150МБ.
По поводу линкера и его тормозов есть такое ключевое слово Ulrich Drepper (http://people.redhat.com/drepper ГДЕ БЛЯТЬ ОФОРМЛЕНИЕ В ДУХЕ wiki? 
DD). Еще, если кто-то интересуется процессом загрузки, то можно посмотреть на примере GNOME: http://www.gnome.org/~lcolitti/gnome-startup/analysis/
DD). Еще, если кто-то интересуется процессом загрузки, то можно посмотреть на примере GNOME: http://www.gnome.org/~lcolitti/gnome-startup/analysis/неплохо.
но совсем без свопа ей имхо и на 256 будет фигово. разве что тексты набивать.
хотя не знаю — не проверял.
но совсем без свопа ей имхо и на 256 будет фигово. разве что тексты набивать.
хотя не знаю — не проверял.
> По поводу линкера и его тормозов есть такое ключевое слово Ulrich Drepper
> Еще, если кто-то интересуется процессом загрузки, то можно посмотреть на примере GNOME:
> http://www.gnome.org/~lcolitti/gnome-startup/analysis/
Это все, конечно, замечательно. Вопрос не в этом. Вопрос в том, почему разработчики GNOME и OpenOffice до сих не могут сделать все по-нормальному, если уже давно известны причины тормозов? Конечному пользователю пофиг на то, как библиотеки грузятся, ему надо чтобы быстро работало.
> Еще, если кто-то интересуется процессом загрузки, то можно посмотреть на примере GNOME:
> http://www.gnome.org/~lcolitti/gnome-startup/analysis/
Это все, конечно, замечательно. Вопрос не в этом. Вопрос в том, почему разработчики GNOME и OpenOffice до сих не могут сделать все по-нормальному, если уже давно известны причины тормозов? Конечному пользователю пофиг на то, как библиотеки грузятся, ему надо чтобы быстро работало.
Вопрос в том, почему разработчики GNOME и OpenOffice до сих не могут сделать все по-нормальному, если уже давно известны причины тормозов?А ты им сколько заплатил за это?
Даже самая богатая компания - Microsoft - и то не с первой версии Windows начала этой проблемой заниматься. Думаешь, потому что там все глупые, и не могли выяснить причины?
Ну, естественно для того, чтобы дать коммерческое ПО имело преимущество хотя бы в desktop-секторе, какие вопросы тут могут быть.
Ну вроде как DT_GNU_HASH сделали. Не знаю только, насколько оно реально помогает. Дождемся выхода 6 федоры через неделю - посмотрим. Обещают, что все полностью будет с ним пересобрано.
> А ты им сколько заплатил за это?
Почему я должен платить за софт, который ху@во работает?
Если будут выпускать качественный софт — я готов платить за него деньги.
См. http://offline.computerra.ru/2006/654/287078/
Почему я должен платить за софт, который ху@во работает?
Если будут выпускать качественный софт — я готов платить за него деньги.
См. http://offline.computerra.ru/2006/654/287078/
> Ну вроде как DT_GNU_HASH сделали. Не знаю только, насколько оно реально помогает.
Это круто! Молодцы ребята! Ждем, когда это попадет в остальные дистрибутивы.
> Дождемся выхода 6 федоры через неделю - посмотрим. Обещают, что все полностью будет с ним пересобрано.
У меня нет доступа к RedHat-based машинам. Если у тебя есть такая возможность, посмотри и опиши впечатления.
Это круто! Молодцы ребята! Ждем, когда это попадет в остальные дистрибутивы.
> Дождемся выхода 6 федоры через неделю - посмотрим. Обещают, что все полностью будет с ним пересобрано.
У меня нет доступа к RedHat-based машинам. Если у тебя есть такая возможность, посмотри и опиши впечатления.
Вообще то можно и ручками прикрутить. Я к gentoo прикручивал по крайней мере. Особого эффекта не заметил - и так все нормально работает
У меня ХР год отлично жила на 112МБ оперативной памяти + 168 свопа (его уменьшить не получалось при этом бОльшую часть времени общая загрузка памяти была около 130-150МБ.
Я помню твои посты в форуме того времени. Нифига это было не отлично =)
Бачан, для винды главное - не наличие/отсутствие свопа, а общее количество памяти.
И 256 без свопа для неё гораздо лучше, чем 150, из которых 50 - своп.
И 256 без свопа для неё гораздо лучше, чем 150, из которых 50 - своп.
а что ты сможешь делать на *NIX с X Window с такими характеристиками, чего нельзя будет сделать с Windows?
Ура! Холивар!
Холивар!+1! Ура!
Много чего
пока еще нет.
пока только червяка закинули
пока только червяка закинули
Почему я должен платить за софт, который ху@во работает?Может быть, с точки зрения авторов, он работает хорошо, потому что у них другие приоритеты. Сдаётся мне, что автор, для которого производительность важнее других вопросов, едва ли станет заниматься GNOME.
> Дождемся выхода 6 федоры через неделю - посмотрим. Обещают, что все полностью будет с ним пересобрано.Ну, я федору 6 ставить буду как только она появится - хочется aiglx на десктоп
У меня нет доступа к RedHat-based машинам. Если у тебя есть такая возможность, посмотри и опиши впечатления.
Так что поделюсь впечатлениями обязательно.
Еще где-то мне попадался мануал как сделать DT_GNU_HASH в генту. Правда, естественно, жутко экспериментально.
Это были посты пекрвых двух месяцев 
> Может быть, с точки зрения авторов, он работает хорошо, потому что у них другие приоритеты.
> Сдаётся мне, что автор, для которого производительность важнее других вопросов, едва ли станет заниматься GNOME.
GNOME — это система пользовательского интерфейса. Для любого пользовательского интерфейса время реакции на действия пользователя очень важно. Это написано в любом руководстве по интерфейсу.
Предложи пример вещей, которые могут быть здесь более приоритетны.
> Сдаётся мне, что автор, для которого производительность важнее других вопросов, едва ли станет заниматься GNOME.
GNOME — это система пользовательского интерфейса. Для любого пользовательского интерфейса время реакции на действия пользователя очень важно. Это написано в любом руководстве по интерфейсу.
Предложи пример вещей, которые могут быть здесь более приоритетны.
Оставить комментарий
yulya
1) Приложения запускаются в разы дольше, чем в winXP. Даже prelink не помогает.2) Где-то слышал этому объяснение, что это происходит из-за того, что большинство виндовых приложений несут в себе все необходимые библиотеки, и подгружать что-то другое им надо реже. Но почему тогда размер их дистрибутивов сравним с размером динамически слинкованных linux-приложений и раза в полтора меньше их же, но статически слинкованных?
3) Непонятно, почему всякие менюшки в иксах, написанные на кроссплатформенных библиотеках (qt, gtk работают медленнее, чем их аналоги в винде. Не говорю уж про родные виндовые кнопочки-окошечки.