Здравствуйте ещё раз, господа форумчане! Мну загорелось очередной бредовой идеей - написать клиент ICQ. Естессно на асме. Причём было решено заложить в него минимально возможные для оконного приложения системные требования (.486, 16MB RAM, Win9х, ну и соответствующие сетевые можности). Зачем - не спрашивайте Одна из причин - практика. Вторая - свободное время Третья - не идёт под 9х квип (версии, валяющиеся сейчас в Тырнете), а ICQ 5.1 юзает ЦП на 90 процентов даже при простаивании, и падает через раз. Можно конечно поставить что-нибудь менее громоздкое или проапгрейдиться. Однако ответы вида "смени комп" или "поставь $program_name$" не рассматриваются. Мы не ищем лёгких путей %) Короче, сейчас прожект находится на завершающем этапе проектировки. И возникла проблема распределения памяти. Согласно придуманной мною архитектуре клиента, у юзера будет возможность держать в общей сложенности 224 контакта максимум в 15 группах (16-я - "общая", т.е. режим без групп). Прошу Вашего мнения: достаточно ли этого? Мне пока что этого даже многовато. Однако у приятеля, например, за год скопилось 134 контакта в 5 группах. У другого (примерно. Точно не считал) - вообще 180 штук... Настораживает. Это правило или исключение? И ст0ит ли поддерживать большее число контактов и групп? В принципе, их можно поддерживать хоть 1000++, однако это усложнит алгоритмы поиска/сортировки. И к тому же, может возрасти нагрузка на память. Вобщем, голосуем и аргументируем. ЗЫЖ: Здесь, на сайте, уже есть подобная вещь. Называется Faim. При попытке запуска весело улетает в BSOD и в 1 из ≈3 случаев валит за собой Венду. Изучать код и искать баги как-то не тянет, ибо писать самому проще чем разбирать чужое.
Учти, что все юзвери давным давно перешли на 2000, ХР и висту На 9х остались только самые извращенцы Поэтому свой клиент нужно ориентировать на извращенцев, а не рядового пользователя ЗЫ: а чем обосновано число 224 / 15 ? ЗЗЫ: чем сортируешь? Надеюсь не пузырьковым алгоритмом?
У меня в контактлисте было около 400 человек, полгода назад поудалял осталось 150. Щас снова понадобавлял кого-то там кто стучит часто, в итоге щас 331 насчитал. Так что если хочешь писать с рассчетом на всех, то рассчитывай на ~500 контактов
Числа обоснованы верхней границей байтовой переменной. 256 записей. Записи, определяющие кнопки управления, кнопки с именами групп и юзеров (каждая запись по 64 байта вместе со строкой имени - меньше уже некуда) хранятся в одном массиве. Только под группы и настройки места зарезервированы. Под настройки - позиции от 0 до 14, под группы - 15-31. Всё что выше - юзеры. Спасибо. Видимо, придётся урезать строку ещё на два байта... Скорее всего - вставочным методом.
Записи целиком. А там и строки (длина фиксирована - 31 байт) и остальные парамы. Добавлено: т.е. память под строку выделяется статически прямо в теле структуры.
Ты пытаешься экономить на мизере, а колоссальных потерь не видишь )) В самом простом примере, чтобы поменять местами 2 строки фиксированной длины, нужно поочередно заменить байты строки А и строки Б. На каждом этапе сортировки у тебя туда-сюда "перегоняется" 62 байта! (31+31) Присвой каждой строке индекс, размеров в 1 байт. Тогда для сортировки, на каждом этапе, все что потребуется, это: 1. Скопировать индекс строки А в регистр 2. Скопировать индекс строки Б на место индекса строки А 3. Скопировать из регистра на место строки Б индекс строки А Работа с регистрами быстрее, чем с памятью. Плюс объемы "перегонки" меньше примерно в 21 раз! Общий выигрыш в производительности, в зависимости от числа строк, будет расти по экспоненте
Хм... согласен! Спс за совет! Только индекс уже придётся делать двухбайтным... А вообще - дельно! Добавлено: Просто никак не определюсь, чтож мне таки нужно - память или производительность. Сортировка будет проходить ну ОЧЕНЬ редко, и стоит ли заводить под это ещё один массив чисел? Впрочем, попробуем и то и другое.
Нет, я конечно понимаю желание оптимизировать все. Но, имхо, в аське самое сложное - реализация самого протокола. Особенно учитывая закрытость последних версий. Ведь сортировка в GUI - это последнее, на что обратит внимание пользователь (если конечно разрабатываемый продукт не для монопольного использования).
Пока что оно и правда разрабатывается чисто "для себя". И кстати о протоколе: у кого-нибудь есть обстоятельные доки по данному вопросу? То что выдаёт мне на первых 3-х страницах Гугль - или не то, или объяснёно вскользь. [+] упс, извиняюсь, нашёл но тем не менее
DEEP По восьмой версии довольно обстоятельно объяснялось. Если нужно, могу раскопать где у меня лежит и выложить куда-нить.
Может хранить контакты и группы лучше не непосредственной адресацией каждого элемента а односвязным списком? Размер каждого элемента данных (данные о пользователе) много больше 4-х байт адреса, поэтому думаю этот метод будет очень эффективным и обеспечит длину списка от нуля до конца адресного пространства Сортировка также очень проста, даже пузырьковым методом
Vov4ick ТС борется за каждый байт, а тут список! Это на 500 контактов порядка 2КБ лишних. И пузырьковая сортировка это худшее, что можно применять. Она неэффективна при любых данных (кроме потоковых).
хы! Два байта были отняты у строки не зря! В рамках массива реализован двусвязанный список: теперь сортировка отпадает вообще! Муахаха %) Правда, пунктам типа "контакт" (в отличие от кнопок управления) оказалось маловато длины записи. Ну да ничего. Ввёл в поле параметров специальный бит "подключена доп. структура". Если включён, значит первые 4 байта строки - указатель на дополнительную 160-байтную структуру, память под которую выделяется динамически. Там содержится UIN, статус, и прочая ботва про контакт. Отсюда ещё один вопрос: скажем, при удалении контакта, его доп. структура чистится, и возникает 160-байтная "дырка" в занятой памяти. А потом (напр, когда добавляется новый контакт) при запросе места под запись она будет заполнена заново, или это уже будет mem-leak? Размеры структур одинаковы. ЗЫЖ: оно уже умеет коннектиться к серваку, менять статус и писать логи пакетов... мну радуецо как дитя
ндя... я был жестоко обманут =( После того как никто из контакт-листа не увидел меня в онлайне и ни до кого из них не дошёл "превед", я внимательно перечитал логи. Оказалось, что эта зараза даже не коннектилась по-нормальному!! %) Логин-пакет сервер хавал на ура, а вот ответный, который приходилось обрабатывать, был сильно неадекватен (с точки зрения имеющихся у меня доков по 7-й версии протокола)... В частности, там где должен размещаться IP сервера и порт назначения, сразу после вызова RECV лежал мой же UIN! А ИП лежит уже после него, плюс к тому по смещению 4. И тайна великая есть, что за WORD находится между ними (второй-то понятно: длина строки ИПа). Вывод: Люди! Делитесь мануалами! Дык конечно возможно! выложу обязательно. Только будет это, видимо, нескоро... экзамены. едрит их ф качель =(
