Обходим чужие тормоза

[crash]

торт!

[Meliborn]

…

[mark_ablov]

занятно, но я всё же работал с файлами истории напрямую, без COM-интерфейса, если важна скорость.

[shodan]

Чем-то не устроило, деталей уверенно не помню. То ли ряд нужных non-message events экспортировать не удавалось, то ли часть messages терялась, тк. отсутствовала в main.db (предположительно хранилась в chatsync).

[oYASo]

Клевая статья. И с технической точки зрения, и с литературной :)

[SkazochNik]

А расскажите про хронометры? Почему 1 или 3? Чего я не улавливаю?

[shodan]

Если два — как понять, который врет?

[SkazochNik]

Врубился. Спасибо.

[d3sp]

Читал до конца в надежде увидеть ссылку на утилитку! Но был жестоко обломлен!
:-)

[d3sp]

Кстати, опаньки, если ты тот Шодан о котором я думаю :) Судя по профилю — тот.

[Harkonnen]

Тот, тот :)

[tangro]

Эм… О ком речь?

[shodan]

Мне уже страшно подумать — о ком.

[Harkonnen]

keyword: Trioptimum

[shodan]

Look at you, hacker, a pathetic creature of meat and bone.

[Harkonnen]

Killed ya on «hard», will do again soon.

[shodan]

Роботов не победить!!!

[tangro]

А это Ваша была прекрасная лекция «Как перестать программировать» на какой-то конференции? Я 2 раза пересматривал, так понравилась.

[shodan]

(шмыгает носом) Моя…

[Harkonnen]

Полагаю, который Sphinx'а сделал.

[shodan]

shodan.ru/files/skype-export-1.1.zip

[d3sp]

Спасибо!
Кстати, нет ли утилитки-подчищалки комментариев хистори? А то штатным способом удаляется вся хистори.

[shodan]

Я ж там написал в самом конце, SQLite Browser. Тушишь скайп, открываешь main.db, там открываешь табличку с мессажками, и далее нехитрыми SQL запросами творишь чудеса.

[d3sp]

На ум приходит анекдот — «Папа, а ты с кем сейчас разговаривал?» ;-)
Но в принципе понятно!

[shodan]

В тематическом блоге по C++ я ожидаю, что еще и не такое понятно.

[S_A]

Рекомендую navicat

[HOMO_PROGRAMMATIS]

Насчет установки Breakpoint для проверки стеков: на самом деле, в CodeAnalyst можно включить сохранение стеков для всех замеров (и это совершенно не тормозит, т.к. работает через встроенный механизм Windows) — во время настройки профайла (там где нужно указать имя профилируемого приложения) найдите маленькую незаметную галочку «CSS» и поставьте.

[HOMO_PROGRAMMATIS]

В прошлых версиях она, кстати, называлась более внятно — Call Stack Sampling

[shodan]

Можно и я пробовал. Только до собственно программы стек не разматывается и поэтому ни в отладчике VS, ни в дереве CA все равно моего кода не видать. Чтобы понять, какой вызов приводит к чему и в каком объеме, так и эдак приходится вручную обставлять программу breakpoint-ами либо printf-ами.

[HOMO_PROGRAMMATIS]

Если до программы не доходило — то вероятно, вы указали слишком маленькое число сохраняемых фреймов. Впрочем возможен и другой вариант — оптимизация EBP, которая не дает нормально раскрутить стек, тогда конечно отладчиком приходится.

[shodan]

Повторюсь, там ОЧЕНЬ МНОГО вложенных вызовов в Skype API видно, если из сисколла глядеть — несколько десятков, возможно, более сотни. Наверняка оно собрано с оптимизациями и потому с одной из точек стек и не разматывается, ага.

[crea7or]

Сколько же там ещё такого говнокода… Скайп ведь ещё тот тормоз.

[shodan]

(пожимает плечами) Меня пока отлично устраивает, если что.

Для старшего поколения вообще единственный вариант, что другое им ставить, чтобы они справлялись с интерфейсом, я не знаю.

А говнокода везде и всюду кучи, не в его наличии или отсутствии счастие.

[stepango]

И с каждой новой версией становится все прожерливее(

[naum]

Skype != skype4com

[iOrange]

циферки всегда кратны 4, и вообще сильно смахивают на размер стека, а вместо ведущей собаки для «публичных» символов типично подчеркивание

странно читать такое в статье про низкоуровневый разбор и API Hooking

[mark_ablov]

угу, манглинг называется.

[FireStorm]

Аналогично, тоже бросилось в глаза. :-) Если что, это стандартное декорирование имён stdcall-функций — _имяФункции@размерАргументовВСтеке. У cdecl декорирование ограничивается только подчёркиванием.
Возможно, такое декорирование специфично только для майкрософтского link.exe.

[tangro]

Ой, Вы знаете, я за свою жизнь уже неоднократно узнавал, что штуки, до которых я дошел своим умом или случайно обнаружил, оказывается, кем-то уже давно придуманы и как-то названы. Когда знакомился с паттернами проектирования — большинство уже были мне известны, просто не знал, что остальной мир их называет вот именно такими именами. Тот факт, что автору не было известно «стандартное декодирование имён stdcall-функций» не имеет никакого абсолютно значения, если ему удалось выполнить поставленную задачу.

[shodan]

Таки нет сил более молчать ;)

Ребята, там ведь в тексте прямо сразу (сразу) после того предложения про циферки русским по белому все (все) написано.

Вы не поверите, наверное, но я того — типа знаю, что такое mangling, зачем в целом нужен, что такое c++filt, чем __stdcall отличается от __fastcall, и еще массу странных вещей.

Конкретных правил декорирования наизусть, разумеется, не помню — тк. требуется единицы раз и не каждый год.

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

Кроме того, заметка написана — не для меня, и даже не для тех, кому слово mangling последние 20 лет родное, ошибки компиляции boost-а читаемы, а всю заметку можно сжать к трем строкам «skype4com дрочил lcmapstringex как одуревший; хукнулся detours-ом; сделал fastpath; начало 3.6x летать; detours сила; skype4com FUUU» совершенно без потерь.

Но, наверное, революционные выводы о степени незнаний автора делать интереснее ;)

[KindDragon]

Вы отправили им баг репорт developer.skype.com/SkypeGarage/ReportIssue?

[KindDragon]

Если напишите, оставьте здесь ссылку на баг, добавлю его в Watch. Надеюсь чем больше людей наблюдей тем больше внимание ему уделят.

[shodan]

Нет, конечно — я даже не знал, что у них есть сколько-то публичный трекер.

[egorinsk]

От этих локалей одно только зло. Как же я их не люблю.

Заметил, что со многими Open Source программами (и не совсем Open Source, например Chrome Browser) теперь идет в комплекте какое-то уродище под названием icudt42.dll весом (да, да, это не опечатка) 11 мегабайт! Это библиотека от IBM (те еще разработчики) для работы с какими-то там кодировками и локалями и она весит 11 мегабайт. Это же ужас какой-то. Мне например вполне хватает пары кириллических кодировок и UTF-8. Мне кажется, это неоптимально и неразумно, ради полувымерших и малораспространенных языков, ставить такую тяжелую бибилиотеку.

Зачем ради всяких недогосударств, которые не могут перейти на нормальную письменность ставить 11-мегабайтную библиотеку? Чтобы они могли на своем недоязыке делать сортировку с учетом локали? по мне, так проще отправить к ним флот нато и убедить перейти на нормальный алфавит, чем сотням миллионов пользователей качать эту гадость.

P.S. Специально зашел на сайт проекта и посмотрел что в этой библиотеке такое тяжелое:

всякие китайские кодировки типа Simplified Chinese (GB18030) (533 Kb), корейские (штук 8 кодировок по 150 Кб каждая, куда им столько??), Break Iterators для языка кхмеров на 832 Кб неужели на нем еще кто-то разговаривает?), Thai word break rules (244 Кб), Collators для китайского и корейского, и еще всякий хлам по мелочи. В Китай, конечно, флот НАТО не отправишь, это печально, но как минимум вынести весь этот треш в отдельную библиотеку для восточных пользователей вполне можно было, ибо 99% людей это не нужно. Грустно становится за сегодняшнее поколение разработчиков из IBM.

[shodan]

> Зачем ради всяких недогосударств, которые не могут перейти на нормальную письменность

Country, Population, GDP
China, 1336M, $10.1T
Russia, 139M, $2.2T
South Korea, 49M, $1.46T
Thailand, 67M, $0.59T

[proxor]

Ещё забыли Японию и Индию.

[Harkonnen]

Вы забыли весовые коэффициенты. Raw Population роли не играет.

[f0b0s]

Вообще-то в ICU как раз все гибко настраивается. Хотите оставить 2 кодировки? Да не вопрос. Перекомпиляция не особо долгая (минут 15).
Собирал ее раз 5 в разных конфигурациях на разных системах. Надежная штука.

И да, про 11 мб в частности: библиотека весит 800 кб + отдельно db файл с кучей таблиц (которые как я написал выше можно вырезать) еще 11. Но так как никто не читает мануал, а в стандартной поставке она в виде одной длл (портабельнее) — то и получается такая говно-длл на 11 мб.

Мораль: не стоит судить хороший инструмент по его некорректному исопльзованию.

[akzhan]

Вот как раз для браузеров имеет смысл ставить все локали. Тот же Chrome используется везде фактически. Не очень хорошо требовать от пользователя выбирать дистрибутив в зависимости от нужных ему языков.

[f0b0s]

А я конкретно про хром и не говорил.
Я лишь указал на то, что egorinsk не прав и все отключается, если нужно.

А то, что полные базы весят 11 мб это же плюс — чем больше база тем больше полезной информации!

[proxor]

На сайт заглядывали, а то, что библиотека, в первую очередь, для Unicode (о чём недвусмысленно намекает её название) — посмотреть поленились. Да, и с точки зрения многих людей, и моей в том числе, иероглифы — вполне нормальная письменность.

[f0b0s]

И кстати она НЕ от IBM. Она начала разрабатываться ими (в 95 году), но это уже давно свободное сообщество. С таким же успехом давайте скажем, что LibreOffice разрабатывается Oracle.

[7vies]

Не понял, как из 5 часов, с ускорением в 3.6 раза получилось 10 минут?

Другой вопрос, учитывая, что это бэкап, нельзя ли его сразу делать инкрементальным, т.е. проскипать все сообщения до определённой даты, не получится быстрее?

[shodan]

5 часов это прикидки (!), причем по числу уже экспортированных чатов, а не мессаг. А там очень неравномерное распределение. Конечная цифра могла быть сильно другая, но я не дождался. 3.6 раза в свою очередь это ускорение на небольшом подмножестве работы, менее 1.5% чатов и менее 0.5% мессаг.

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

Инкрементально делать сложнее, интерфейс не способствует. Плюс сама идея городить инкрементальные бэкапы для 30 мб текста из 200 мб базы меня коробит, на таких объемах полный экспорт обязан длиться разумное время.

[sluge]

интересно, а при первом прогоне в профайлере можно было увидеть, что всех больше отъела времени именно LCMapStringW?

[shodan]

Теоретически можно, если поставить Call Stack Sampling. Практически, в данном случае оно тоже подбрехивает. LCMapStringW в профайле низко; LCMapStringEx высоко. Но по факту LCMapStringEx адскую кучу раз вызывается именно из LCMapStringW и именно W я перехватываю.

[KAFLAN]

Я конечно все понимаю штука безусловно полезная, но что бы библиотека стоила как low-end автомобиль это лихо www.microsoftstore.com/store/msstore/en_US/pd/productID.216531800/search.true (версия поддерживающая 64-х битные приложения и коммерческое использвоание, которых сейчас развелось пруд пруди).

[dasty]

Спасибо за статью.