формально - массив это просто объект

https://gist.github.com/DmitrySoshnikov/593e19f60df257f2119fad2e0431b617

такое на прокси надо делать

единственный плюс использования массива против объекта это то, что у него ключи пронумерованы? В остальных случаях лучше использовать объект, получается. Потому что массив тоже объект.. госпаде почему так

Не совсем так. На сайте v8 рассказано про оптимизации

единственный плюс использования массива против объекта это то, что у него ключи пронумерованы? В остальных случаях лучше использовать объект, получается. Потому что массив тоже объект.. госпаде почему так

По-моему, тебе Map нужен

Map что-то грустный. Есть ли структура с быстрым удалением по середине?

формально - массив это просто объект

Без гарантированной сортировки свойств

Map что-то грустный. Есть ли структура с быстрым удалением по середине?

R.remove(2, 3, [1,2,3,4,5,6,7,8]); //=> [1,2,6,7,8]

И?

Чем оно быстрее /лучше?

Чем оно быстрее /лучше?

Из мапов можно удалять элементы.

В них ключами могут быть не только строки.

Из мапов можно удалять элементы.

не не ( я про задавайте свои ответы)

а?

про Map я знаю - проверял - не подходит. Слишком медленна реализация

возможно стоит написать конечно свой Map

с нужной мне балансировкой

а что тебе нужно?

Быстрое удаление из середины(хотя скорее будет ближе к началу)

А чем объекты плохи? В них удаленные элементы память не занимают же.

паммять не занимают - но деоптимизируют

ну и на самом деле и то и другое при удаление конечно только помечается к гц на расмотрение. ну вообщем-то можно и объекты использовать, но удалять с середины все равно нужно перемещения делать O(n/2) раз в ближайшую сторону

Люди, такой вопрос

Я писал игру простенькую на ноде (на сокетах). И игроков хранил в массиве с их данными позиций Х и Y

но когда добавляется 1-2 юзера, память засорялась

такие данные надо хранить онли в бд?

ну и на самом деле и то и другое при удаление конечно только помечается к гц на расмотрение. ну вообщем-то можно и объекты использовать, но удалять с середины все равно нужно перемещения делать O(n/2) раз в ближайшую сторону

Какие перемещения? Объекты это хеш структура же

такие данные надо хранить онли в бд?

можешь в файликах )) хотя это по сути тоже бд... файловая

Какие перемещения? Объекты это хеш структура же

а ты всегда хочешь читать не существующие проперти? или какие-то есть другие ухищрения?

можешь в файликах )) хотя это по сути тоже бд... файловая

не быдло код?

в файлах

а ты всегда хочешь читать не существующие проперти? или какие-то есть другие ухищрения?

new Object(null)

new Object(null)

я про задачу удалить из середины массива

Сделать свой HashMap. Сделать свои деревья поиска. Сделать свой deque

я про задачу удалить из середины массива

x = {1: 3, 2: 6, 6:7}; delete x[2]

Сделать свой HashMap. Сделать свои деревья поиска. Сделать свой deque

а то тут недавно кто-то жаловался, что алгоритмических структур не хватает

Я и жаловался :P

я про задачу удалить из середины массива

splice

вообще от задачи все зависит

splice

он дороговат в плане скорости работы

x = {1: 3, 2: 6, 6:7}; delete x[2]

так-то это не массив

Я писал игру простенькую на ноде (на сокетах). И игроков хранил в массиве с их данными позиций Х и Y

ну вообще можешь и так делать но если хочешь чтобы было многопользовательской эта история то наверное стоит переделать на какое-нибудь хранилище которое будет работать и с другими тредами

Сделать свой HashMap. Сделать свои деревья поиска. Сделать свой deque

есть объекты, есть map

он дороговат в плане скорости работы

про это ничего в постановке задачи нет

x = {1: 3, 2: 6, 6:7}; delete x[2]

ну delete же деоптимизирует и все становится грустно тут же

Куда деоптимизирует? элементы и так хранятся по хешам а не по ключам

по-моему splice самый адекватный метод

если скорость не важна и нужны именно массивы то да

чуваки, а за вопрос по mysql в этом чатике меня не побьют? в качестве оправдания могу сказать, что использую его в node.js =)

Куда деоптимизирует? элементы и так хранятся по хешам а не по ключам

а ты пытался использовать или читал про деоптимизацию? или там уже поменялась деоптимизация такого кода?

а ты пытался использовать или читал про деоптимизацию? или там уже поменялась деоптимизация такого кода?

ну я объекты в качестве кеша иногда использую, вроде ни по памяти ни по скорости просадки со временем не знамечал, при это сервис по 5к запросов в секунду нормально обрабатывал в течении нескольких месяцев

https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#52-the-object-being-iterated-is-not-a-simple-enumerable

И всё-таки, где вы наблюдали проблемы по скорости у Map?

На свежих версиях.

Гонять туда-сюда объекты с двумя фиксированными полями — объекты быстрее

хранить-добавлять-удалять кучу всего надолго — мапы быстрее

Ну, в тех тестах, что я видел.

https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#52-the-object-being-iterated-is-not-a-simple-enumerable

а да, про это читал, но реальной просадки не видел ни разу, видимо это когда по 100к операций в секунду выполняешь будет только заметно

у меня обычно есть в коде намного более медленные операции что бы на скорость хеш таблиц внимание обращать

это как раз про массив. map замедляется явно со временем у меня типа есть id request’а же и я его посылаю типа по 5к за раз элементов по сути в мапе создаю дальше удаляю как приходит ответ по сути. со временем спустя миллион наверное удалений оно замедляется

есть подозрение что все таки пока гц не постучит в ворота хранится там какая-то таблица просто с пометками к удалению

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

WeakMap шустрее мапа но в нем нельзя получить список всех элементов

спасибо - надо будет попробовать

x = {1: 3, 2: 6, 6:7}; delete x[2]

бум, и код неоптимизируемый

ERROR: S client not available

бум, и код неоптимизируемый

да, но на сколько часто ты в реальных проектах встречал заметное влияние от этого? я вот раньше тоже и for .. in .. избегал потому что он не оптимизируемый, потом просто забил на это и не заметил разницы

ну не код, а именно эта структура. там если больше 1ой тысячи элементов что ли оно проваливается в hash table mode

у меня там больше 1000 элементов, деркается она по несколько тысяч раз в секунду, раз в несколько минут перебирается полностью и вычищаются элементы с истекшим ttl, просадки в скорости не замечал

ну попробуй сравнить с другими решениями

просто это может быть не узким местом - но не факт что самым быстрым решением

если что то надо прямо совсем оптимизировать то мне проще это на го переписать... он в некоторых местах оптимальнее работает

просто это может быть не узким местом - но не факт что самым быстрым решением

ну если есть узкие места то надо в первую очередь на них смотреть и оптимизировать а не на то, что не идеально оптимизировано

да, но на сколько часто ты в реальных проектах встречал заметное влияние от этого? я вот раньше тоже и for .. in .. избегал потому что он не оптимизируемый, потом просто забил на это и не заметил разницы

почему просто не сделать копию объекта без удаляемого ключа? быстро и оптимизируемо

почему просто не сделать копию объекта без удаляемого ключа? быстро и оптимизируемо

если элементов много то копирование это крайне медленная операция

ну если есть узкие места то надо в первую очередь на них смотреть и оптимизировать а не на то, что не идеально оптимизировано

я спорить на этот счет не буду. у меня вот эта штука теперь является узким местом, хотя пока думаю что хватит какого-нибудь https://github.com/Salakar/denque потому как ну почти всегда нужный элемент сначала находится

почему просто не сделать копию объекта без удаляемого ключа? быстро и оптимизируемо

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

@klond90 тебе нужен кастомный hashtable, без вариантов

Будет за O(1) все

Как пример что взять?

Речь ведь все ещё про тарантул?

да да я все еще не разогнал ту очередь но нашел инетресный вариант

Смотри, берёшь массив фиксированной длины N

Из предположения, что число исходящих запросов в нормальных ситуациях будет <N

В качестве хэша берёшь %N

В каждой ячейке массива - голова односвязного списка

да я что-то такое продумывал надо посмотреть. 10кратный прирост может быть спокойно на длинной очереди

Прирост чего?

поиска/удаления

Ну вопрос, насколько это повлияет на общую производительность

оно начинает быть узким местом когда по 5к запросов за раз уходит

@vkurchatkin предложил им явно ничего не ломающий метод: https://github.com/gulpjs/gulp/issues/1640#issuecomment-240683358

Если уж и это ему не понравится, то я даже не знаю.

*забыл запятую, в смысле это я обращаюсь к @vkurchatkin и я предложил

Что думаешь?

парни, я иногда пропускаю много тут. речь о том, что gulp тормозит ноду из-за vinyl-fs, который поломается (в ноджс 7?), я правильно понимаю??

/лучше