Safari

[oort]

А sqlite3 vacuum на эти базы проводился?

Не понял значения слова "проводился" в этом контексте

for i in path-to-profile/*.sqlite; do sqlite3 $i vacuum; done

Под виндом другой синтаксис, которого я не помню, с таким же смыслом.

[myst]

И такое ощущение, что программисты Сафари (как и ФФ) не слышали о free/delete.

В Objective-C не осилили уборщик мусора?

[myst]

myst, ты случаем не устроился на подработку рекламировать Оперу? А мы-то думаем, кому ты там переводишь...

Нет. Просто Опера реально лучший браузер. Чесно-чесно.

[myst]

Так сложно просмотренные страницы кешировать где-то на жёстком диске, если уж так их жмёт кешировать?

Кто-то недавно хвалился гигабайтами памяти. Так вот, разработчики на таких и ориентируются. И это правильно, нечего памяти пустовать.

[myst]

Более того, закрытие одной вкладки из большого числа открытых занимает много времени (иногда очень много), но память не особенно высвобождается.

Чиво?! У меня постоянно больше 100 вкладок открыто. Никаких тормозов на закрытии вкладок никогда не видел. Память Опера освобождает нормально, с небольшой задержкой в несколько секунд. Корзину закрытых вкладок очищать пробовали?

[myst]

Я не понимаю, чего там такого выделять на 43 мегабайта (!!) на одну закладку?

Исходники WebKit'а открыты, бери да кури. Если, конечно, это он «виноват».

[Лукас]

Нет. Просто Опера реально лучший браузер. Чесно-чесно.

А мы таки поверили!

[Алексей Гринь]

В Objective-C не осилили уборщик мусора?

В спецификации Objective-C 2.0 он есть, но можно выключать опцию и компилить без него. Под Apple реализация его имеет, а когда последний раз ковырял Objective-C под minGW, там не было ни сборщика мусора, ни исключений (точнее исключения компилировались без ошибок, но запуск программы вызывал сегфолт... может быть я не те либы подключал). Но то было 1.5 года назад и не правда. Чай, поменялась ситуация. Обжектив Си прикольный.

Так сложно просмотренные страницы кешировать где-то на жёстком диске, если уж так их жмёт кешировать?

Кто-то недавно хвалился гигабайтами памяти. Так вот, разработчики на таких и ориентируются. И это правильно, нечего памяти пустовать.

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

Исходники WebKit'а открыты, бери да кури. Если, конечно, это он «виноват».

Шарики за ролики не заедут осиливать?

[myst]

И пофиг ведь шо у бедного пользователя на одну кнопочку выделяется по 10 мб, всё тормозит и виснет

Так ить не факт, что это гуй память съедает. Может, это движок такой прожорливый.

[Алексей Гринь]

Блин, я всё надеюсь на умные алгоритмы в современных программах... Думал, Сафари много памяти жрёт, потому что там какая-нибудь циклическая синхронизированная сборка мусора, т.е. не каждый момент, а через некоторые определённые интервалы времени, чтобы освобождать не по козявке, а целыми блоками (например можно было бы активировать огда пользователь неактивен, т.е. отошёл или просто читает страницу - не заметно бы было; эти два таба наверно реально жрут по 60 мб, ппц. Если нет, то они полные идиоты, если эт всё закешированные образы просмотренныхз страниц печальным грузом висятs). Хрен с два. Оставил два таба на 6 часов... Как было 124 МБ, так и осталось (за 6 часов не сообразил неиспользуемое заархивировать...)
21 век, ага. Программы как будто пишутся с помощью лома.

[myst]

21 век, ага. Программы как будто пишутся с помощью лома.

У тебя есть возможность написать свой браузер с циклической синхронизированной сборкой мусора, блекджеком и шлюхами.

[Алексей Гринь]

Я не выёживаюсь, я говорю какбэ логичные вещи. 21 век на дворе, терабайты и гигагерцы, а программы в целом по производительности как лет двадцать назад. В Adobe Premier Pro случается жуткая утечка памяти при импорте видео, выведенного из Flash. Я ипу.
В попу такой быдлокодерский мир, пойду повешусь.

[wienski]

Пропагандируйте ассемблер для архитектуры x86-64 

[myst]

В попу такой быдлокодерский мир, пойду повешусь.

Постой, не спеши! Скоро Common Lisp захватит мир, и наступит щастье.

[Алексей Гринь]

Шо-то у сафари частенько табы виснут (не реагируют на нажатия), и курсор меняет на забавный и начинает мерцать (это как было в версии 3.0, так и осталось в 4.0-ой).

[myst]

Шо-то у сафари частенько табы виснут (не реагируют на нажатия), и курсор меняет на забавный и начинает мерцать (это как было в версии 3.0, так и осталось в 4.0-ой).

Кошерный Объектный Си не помог?

[Алексей Гринь]

Язык-то тут причём? Дело в кривоватом порте библиотек CoreFoundation с Mac OS на Windows.

[myst]

Язык-то тут причём? Дело в кривоватом порте библиотек CoreFoundation с Mac OS на Windows.

Ага, как кривое поделие на С++, так язык виноват, а как на Объектном Си, так...

[Алексей Гринь]

Ага, как кривое поделие на С++, так язык виноват, а как на Объектном Си, так...

Э? У Си++ убогий синтаксис и убогая семантика. Реализации шустрые, но медленнее, чем в Си. В объектном Си хороший синтаксис и хорошая семантика. Но так как там все методы виртуальные, реализации Объектного Си в основном всегда медленнее С++. Я это знаю и не отрицаю.
Но при чём здесь вообще это? Я говорю, что конкретно библиотеки, которые эмулируют АПИ Mac OS конкретно под Windows кривые в плане GDI. При чём здесь вообще реализиции конкретныз языков?
Почуй разницу:
  1) в gcc-реализации С++ стандартные конструкторы медленнее, чем то же средствами С.
  2) в порте-реализации CoreFoundation под WinApi32, скомпиленнной gcc, есть некоторые баги.
Первое это реализация стандарта языка, второе - реализация сторонней частной библиотеки.

[myst]

1) в gcc-реализации С++ стандартные конструкторы медленнее, чем то же средствами С.

Ты мне исходники этого теста так и не дал. Так шта пока не верю.

[myst]

У Си++ убогий синтаксис и убогая семантика.

Тогда ты должен не любить и синтаксис Си, так как именно его синтаксис составляет основу синтаксиса C++.

[Алексей Гринь]

Ты мне исходники этого теста так и не дал. Так шта пока не верю.

Я же давал где-то.

Си:

typedef struct
{
   int x, y;
} CLala;
CLala* CLala_create(int x, int y)
{
   CLala* self = malloc(sizeof(CLala));
   self->x = x;
   self->y = y;
   return self;
}

Си++

class CPLala
{
public:
   int x, y;

  CPLala(int x, int y): x(x), y(y) { }
};

И потом в цикле

   CPLala* lala = new CPLala(10, 20);
   delete lala;

и

   CLala* lala = CLala_create(10, 20);
   free(lala);

Тогда ты должен не любить и синтаксис Си, так как именно его синтаксис составляет основу синтаксиса C++.

Я имел в виду убогий синтаксис той фишки, которую они представляют как главное достоинство, — ООПа. Синтаксис ООПа кривой по сравнению с Обж-С (как и семантика). Синтаксис же собсно Си не критикуем, ибо классика

[Алексей Гринь]

А по теме: я-таки перелез обратно на ФФ.
Сафари надоел тремя вещами:

1) глючит курсор, самопроизвольно меняется на другой и мерцает
2) зависают табы
3) половина юникода показывается квадратами, совсем не упёрлось думать, как это порешить
4) ну и ещё по мелочам, типа нет списка только что закрытых табов, а История показывает какое-то невразумительное пустое чёрное окно...
5) Да и Top Sites оказался бесполезен.

[Хворост]

А по теме: я-таки перелез обратно на ФФ.

Поздравляю!

[myst]

Я же давал где-то

Ну что я тебе могу сказать? Проблема эта даже не в самом gcc, а в библиотеке. Язык тут вообще не при чём. В VC С++-вариант даже быстрее (на 100 млн. итераций разница больше секунды на моём процессоре). Так-то.
Переопредели new и delete, чтобы они просто вызывали malloc и free соответственно, и результаты станут одинаковыми.
Вообще, тест отдельной реализации — это именно тест реализации, а не языка. Язык не может быть быстрым или медленным, нет у него такого качества.