Ну формальное требование — «не медленнее», значит, бенчмарк должен банально замерять то, что каждая из операций выполняется не медленнее: creating, updating, traversal. Это можно достигнуть только через вот да, эти «волшебные» ключи, потому что даже выборка по двум ключам не так эффективна.
Теоретически — да, это, пожалуй, единственный вариант, но апи будет такииим гемморойным… К тому же — придется кэшировать строки, потому что операция создания строки '__prev_' + x тоже ресурс жрет. Соответственно — нужна автоматическая генерация строк с их кэшированием.
В итоге код будет вида list[prevKey[x]], что в итоге тоже равно является выборкой по ключам. В итоге — тоже не катит.
Примесью в виде красивого ООП — я уже сказал, это чистый WeakMap, есть замечательный полифилл от Брэндона Бенви, который сумел создать скрытые свойства элементов и на этом сделал поддержку множественных WeakMap на одном объекте, у которых не течет память. Код практически эквивалентен, я как раз начал ковыряться с того, что взял его полифилл и выкинул все лишнее. Получилось именно так, как я сказал выше — двойная выборка по ключам, и минимальная просадка по перформансу. И вот что с этим дальше делать — вообще без понятия.
Задача откровенно дурацкая, к слову. Одновременно простая и невозможная.
Если нужно именно сохранить сложность O(1) и O(n) для добавления/удаления и поиска соответственно, и допустимы незначительные замедления (доли или единицы процентов от общего времени выполнения) из-за добавления дополнительного функционала — решение элементарное.
Банально заменяется обращение к _idleNext и _idlePrev на что-то вроде для, например, функции peek
function peek(list) {
if (list.__prevPointers[listKey] == list) return null;
return list.__prevPointers[listKey];
}
То есть решение довольно очевидное и «в лоб». Функция сложности не меняется, но возрастают затраты на дополнительные обращения.
А вот дальше начинается абсолютная дурость. Из-за неизвестной среды исполнения становится непонятно, что можно и что нельзя использовать, потому что подобный код замечательно оптимизируется через WeakMap, который может очень хорошо дать прироста в нативном исполнении.
А больше его и не оптимизировать толком никак, потому что проще и эффективнее, чем это сделано сейчас, сделать не выйдет. В основном потому что код практически эквивалентен определению двусвязного списка самого по себе и не обладает дополнительным обвесом из кода, оптимизировать его возможно будет только под какие-то специфические платформы. Либо сделать извращенную реализацию двусвязного списка поверх — опять же — какого-нибудь WeakSet, но тут вновь вопрос о том, какие требования по платформам.
Neo4j — то еще днище, если честно.
У меня сейчас аналогичная задача, только практическая — «отражение» части социального графа ВК на локальную базу, чтобы потом над ним манипулировать.
Оно отожрало все ресурсы системы (стандартный сервер за 20 баксов, ssd, 2 гига, 2 ядра) и медленно стагнирует, сейчас в базе около 0.3кк нод (с минимально нужным количеством данных, у большинства даже текстовых полей нет), они набились где-то за 3 дня. Мои теоретические расчеты говорили мне, что за 3 дня у меня будет все «отражение» в ~20кк нод, в жизни не думал, что уткнусь в производительность записи БД.
Запросы при этом уже оптимизированные, до оптимизаций за три дня было создано где-то 40к нод.
Сейчас либо переведу все на Titan, либо банальный postgres возьму, потому что так жить нельзя.
Ого. Огромная просьба — а можете выложить скрипт для запросов к ВК?
Перевожу одну систему с JS на Ruby, ой как не хочется переписывать многопоточную молотилку запросов с execute.
А еще лучше GitHub pages. По одной простой причине — он отдает данные БЫСТРЕЕ, чем даже akimai. Вот с cloudFlare не сравнивал еще.
Я туда проект переложил не так давно с отдельного хостинга
С одной стороны — я согласен, с другой стороны — по-моему это троллинг. Вот честно, хочу одновременно и плюс и минус влепить.
А насчет…
Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust. Для чего они существуют — не очень понятно
Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
Если интересно — гуглите fast low-memory SVD.
В ES7 этих proposal-ов приватных свойств чуть ли не больше чем реализаций классов на JS.
Вот, например, что в свое время поддерживал babel как экспериментальную фичу (уже нет)
Как раз на викмапах работало. Что тоже не очень честно. Можно сделать паблика морозова при желании.
А вообще — если серьезно — ну не надо этой приватщины в джаваскрипте. Есть договоренность о том, что свойства с _ в начале — приватные и никто в них не лезет. И всем хорошо. Дебажить удобнее, работать удобнее, никакого геммороя.
извиняюсь, был напуган. Там прямое переписывание html идет.
Вообще показалось, что XSS возможен. На деле возможно вроде только сломать верстку, начав вводить <, например.
На больших страницах (примерно 60 кб текста) скрипт зависает на пару минут. Все функции измерил таймерами — отрабатывают быстро (в пределах 300 мс в IE, 100 мс в Chrome). Если кто-то сможет подсказать причину — буду очень признателен.
Надо смотреть профилирование, а не таймеры.
И надо оптимизировать код, очень много что можно закэшировать, очень много что можно просто ускорить. Отказаться от jquery тоже хорошо поможет.
А вообще я в принципе удивлен, что оно работает толком: нормальный поиск делается не так. Для клиента, например, можно взять Lunr
Для применения и снятия выделения наиболее эффективно будет использовать ContentEditable, а не тупую замену регуляркой.
К всем этим обсуждениям тут.
Я сейчас попал на относительно долгое время в США — был уже раньше тут, но не готовил сам — и буквально вчера сам начал пересматривать взгляды на ГМО.
Тут очень, гхм, интересные овощи.
К арбузам без косточек мы все привыкшие, пусть экзотика, но «ладно, они специально такой сорт вывели». Но именно вчера были два очень интересных наблюдения:
-куплен десяток помидоров, про них все забыли, они лежали себе спокойненько. Что примечательно — лежали в двух разных плошках на разных полках. Позавчера увидел, твердые, нормальные, подумал «нужно на завтрак будет взять». С утра — как по команде, в обоих плошках половина мягкие, половина заплесневели. Ощущение, как от айпада, в котором качелька громкости на 181 день должна ломаться была.
-куплена картошка. То, что одного размера — ладно. То, что половина черная (да, у них такой сорт есть) — ладно. Но я специально посмотрел вчера после приготовления — ни одного картофельного глазка или намека на него хотя бы. Я думал, про «вырожденные семена» — это относительно байки, что просто из этих семян ничего не растет, но по факту — эта картошка конечный этап эволюции. Как потребителю мне все равно, как технарю — мне представляются сложные схемы воспроизводства рассады для подобной картошки.
Не, не спорю. ГМО это не плохо, плавники ни у кого не вырастут, это бред. Но прикол в том, что оно используется не факт что исключительно для хороших целей.
Вполне возможно, я стал более чем уверен, что в часть овощей засаживают, например, фичу «начать быстро портиться, когда положат в +2 градуса» (обратите внимание, в магазинах фрукты и овощи хранятся в комнатной температуре, но дома почему-то мы все тащим в отделение для свежих овощей в холодильнике). Добро пожаловать в новый дивный мир.
Теоретически — да, это, пожалуй, единственный вариант, но апи будет такииим гемморойным… К тому же — придется кэшировать строки, потому что операция создания строки '__prev_' + x тоже ресурс жрет. Соответственно — нужна автоматическая генерация строк с их кэшированием.
В итоге код будет вида list[prevKey[x]], что в итоге тоже равно является выборкой по ключам. В итоге — тоже не катит.
Примесью в виде красивого ООП — я уже сказал, это чистый WeakMap, есть замечательный полифилл от Брэндона Бенви, который сумел создать скрытые свойства элементов и на этом сделал поддержку множественных WeakMap на одном объекте, у которых не течет память. Код практически эквивалентен, я как раз начал ковыряться с того, что взял его полифилл и выкинул все лишнее. Получилось именно так, как я сказал выше — двойная выборка по ключам, и минимальная просадка по перформансу. И вот что с этим дальше делать — вообще без понятия.
Если нужно именно сохранить сложность O(1) и O(n) для добавления/удаления и поиска соответственно, и допустимы незначительные замедления (доли или единицы процентов от общего времени выполнения) из-за добавления дополнительного функционала — решение элементарное.
Банально заменяется обращение к _idleNext и _idlePrev на что-то вроде для, например, функции peek
То есть решение довольно очевидное и «в лоб». Функция сложности не меняется, но возрастают затраты на дополнительные обращения.
А вот дальше начинается абсолютная дурость. Из-за неизвестной среды исполнения становится непонятно, что можно и что нельзя использовать, потому что подобный код замечательно оптимизируется через WeakMap, который может очень хорошо дать прироста в нативном исполнении.
А больше его и не оптимизировать толком никак, потому что проще и эффективнее, чем это сделано сейчас, сделать не выйдет. В основном потому что код практически эквивалентен определению двусвязного списка самого по себе и не обладает дополнительным обвесом из кода, оптимизировать его возможно будет только под какие-то специфические платформы. Либо сделать извращенную реализацию двусвязного списка поверх — опять же — какого-нибудь WeakSet, но тут вновь вопрос о том, какие требования по платформам.
У меня сейчас аналогичная задача, только практическая — «отражение» части социального графа ВК на локальную базу, чтобы потом над ним манипулировать.
Оно отожрало все ресурсы системы (стандартный сервер за 20 баксов, ssd, 2 гига, 2 ядра) и медленно стагнирует, сейчас в базе около 0.3кк нод (с минимально нужным количеством данных, у большинства даже текстовых полей нет), они набились где-то за 3 дня. Мои теоретические расчеты говорили мне, что за 3 дня у меня будет все «отражение» в ~20кк нод, в жизни не думал, что уткнусь в производительность записи БД.
Запросы при этом уже оптимизированные, до оптимизаций за три дня было создано где-то 40к нод.
Сейчас либо переведу все на Titan, либо банальный postgres возьму, потому что так жить нельзя.
Перевожу одну систему с JS на Ruby, ой как не хочется переписывать многопоточную молотилку запросов с execute.
Я туда проект переложил не так давно с отдельного хостинга
А насчет…
Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
Если интересно — гуглите fast low-memory SVD.
-Tell me, ma chère, what stands between sex… and fear?
-fünf!
Про пример — да, извиняюсь, this::x поддерживался, а не @x, перепутал.
Вот, например, что в свое время поддерживал babel как экспериментальную фичу (уже нет)
Как раз на викмапах работало. Что тоже не очень честно. Можно сделать паблика морозова при желании.
А вообще — если серьезно — ну не надо этой приватщины в джаваскрипте. Есть договоренность о том, что свойства с _ в начале — приватные и никто в них не лезет. И всем хорошо. Дебажить удобнее, работать удобнее, никакого геммороя.
А можно поподробнее?
Вообще показалось, что XSS возможен. На деле возможно вроде только сломать верстку, начав вводить <, например.
Надо смотреть профилирование, а не таймеры.
И надо оптимизировать код, очень много что можно закэшировать, очень много что можно просто ускорить. Отказаться от jquery тоже хорошо поможет.
А вообще я в принципе удивлен, что оно работает толком: нормальный поиск делается не так. Для клиента, например, можно взять Lunr
Для применения и снятия выделения наиболее эффективно будет использовать ContentEditable, а не тупую замену регуляркой.
Вот это вообще страшно, тут при должных навыках можно даже инъекции сделать. Особенно вкупе с прямой ссылкой
Парни, а давайте я вам надаю старой электроники, а вы мне люмию?
Я сейчас попал на относительно долгое время в США — был уже раньше тут, но не готовил сам — и буквально вчера сам начал пересматривать взгляды на ГМО.
Тут очень, гхм, интересные овощи.
К арбузам без косточек мы все привыкшие, пусть экзотика, но «ладно, они специально такой сорт вывели». Но именно вчера были два очень интересных наблюдения:
-куплен десяток помидоров, про них все забыли, они лежали себе спокойненько. Что примечательно — лежали в двух разных плошках на разных полках. Позавчера увидел, твердые, нормальные, подумал «нужно на завтрак будет взять». С утра — как по команде, в обоих плошках половина мягкие, половина заплесневели. Ощущение, как от айпада, в котором качелька громкости на 181 день должна ломаться была.
-куплена картошка. То, что одного размера — ладно. То, что половина черная (да, у них такой сорт есть) — ладно. Но я специально посмотрел вчера после приготовления — ни одного картофельного глазка или намека на него хотя бы. Я думал, про «вырожденные семена» — это относительно байки, что просто из этих семян ничего не растет, но по факту — эта картошка конечный этап эволюции. Как потребителю мне все равно, как технарю — мне представляются сложные схемы воспроизводства рассады для подобной картошки.
Не, не спорю. ГМО это не плохо, плавники ни у кого не вырастут, это бред. Но прикол в том, что оно используется не факт что исключительно для хороших целей.
Вполне возможно, я стал более чем уверен, что в часть овощей засаживают, например, фичу «начать быстро портиться, когда положат в +2 градуса» (обратите внимание, в магазинах фрукты и овощи хранятся в комнатной температуре, но дома почему-то мы все тащим в отделение для свежих овощей в холодильнике). Добро пожаловать в новый дивный мир.