bimcom: Это мысль, наверняка получится сэкономить 20-40% используемой памяти.
А вот замена на кирилицу всех данных эффекта никакого не дала.
Странно. Они должны храниться в памяти в юникоде. Хотя может при замене теперь лишняя память, ранее выделенная под строку, не высвобождается...
Слава Шевцов добавил 17.05.2009 в 13:33
netwind: а что вы делали в БД? может просто грамотно переписать?
в SQL с данными можно делать почти все что угодно. а при использовании хранимых процедур и курсоров - вообще все
Не всё. Далеко не всё. А некоторые вещи - очень медленно. Например, когда индекс не вмещается в память.
bimcom, Вы лучше опишите задачу целиком. Без бизнеса - только техническую часть. Может что подскажем по архитектуре. Либо в личку ;)
Ещё большее сжатие данных основывается на том, что многие имена часто повторяются и фамилии тоже не уникальные => можно разбить "имя фамилия" на два доп. массива. Один содержит $names['Имя'] = (int)$id1, второй - $families['Фамилия'] = (int)$id2. Имена и фамилии сортируются по частоте упоминания так, чтобы самые популярные имели наименьшие номера. Тогда $w[0] = "Андрей Кузнецов" можно записать как $w[0] = "1_1".
Можно ли имена и фамилии сжать так, чтобы $id1*const + $id2 < MAX_INT и $id1*const + $id2 были всегда уникальны - не в курсе. Смотрите на своих данных ;)
2. $w[0] нужно транслитерировать в английские буквы, если по этому параметру происходит только поиск (соответственно, при поиске поисковая строка тоже транслитерируется).
Это мысль, наверняка получится сэкономить 20-40% используемой памяти.
А вот замена на кирилицу всех данных эффекта никакого не дала.
Странно. Они должны храниться в памяти в юникоде. Хотя может при замене теперь лишняя память, ранее выделенная под строку, не высвобождается...
Слава Шевцов добавил 17.05.2009 в 13:33
а что вы делали в БД? может просто грамотно переписать?
в SQL с данными можно делать почти все что угодно. а при использовании хранимых процедур и курсоров - вообще все
Не всё. Далеко не всё. А некоторые вещи - очень медленно. Например, когда индекс не вмещается в память.
bimcom, Вы лучше опишите задачу целиком. Без бизнеса - только техническую часть. Может что подскажем по архитектуре. Либо в личку ;)
Ещё большее сжатие данных основывается на том, что многие имена часто повторяются и фамилии тоже не уникальные => можно разбить "имя фамилия" на два доп. массива. Один содержит $names['Имя'] = (int)$id1, второй - $families['Фамилия'] = (int)$id2. Имена и фамилии сортируются по частоте упоминания так, чтобы самые популярные имели наименьшие номера. Тогда $w[0] = "Андрей Кузнецов" можно записать как $w[0] = "1_1".
Можно ли имена и фамилии сжать так, чтобы $id1*const + $id2 < MAX_INT и $id1*const + $id2 были всегда уникальны - не в курсе. Смотрите на своих данных ;)
Девушки у нас будут. Вопрос знатокам: зачем нам Джефа с лопатами? 😂
Как уменьшить расход памяти:
1. "=str_replace" -> "=(int)str_replace"
2. $w[0] нужно транслитерировать в английские буквы, если по этому параметру происходит только поиск (соответственно, при поиске поисковая строка тоже транслитерируется).
Здесь просто пиар, причём, достаточно тупой. Типо, такие крутые, закрытый клуб, пускают только по рекомендациям.
Чем тупее работающий бизнес, тем больше он стоит.
Докупите память и не мучайтесь. Дешевле выйдет.
Хотя можете и код сюда кинуть на посмотреть.
Если хостер нормальный, то, что бы пользователь не творил внутри своего ВПС - хостеру пофиг.
Это не так. Читайте условия договоров и найдёте много интересного. Например, право убивать программы, если они долго работают и их назначение не ясно.
Слава Шевцов добавил 17.05.2009 в 12:06
По мне так на каждую задачу, своё оборудование.
А мне бы на все задачи - одно. Я же не хостер 🚬
Мы, белорусы - гостеприимный народ
Также могу оказать посильную помощь в посещении злачных мест
Смотрю на аватарку и как-то сразу хочется с Вами в злачные места... 😂
Так в синхронном плавании есть командные выступления.
Ага. Вода. Тишь. Гладь. И тут из неё... вертикально... поднимаются... 9 ножек... лохматых ножек....
** дурацкая была тут шутка ***