Массив объектов или объект объектов
 

Достопочтенная публика, на ваше публичное осуждение выставляется мой замутненый разум, в значительной степени ОН расщепленный.
Если Array - объект, и содержит объекты то это как не крути массив объектов со всеми присущими тратами памяти, с другой стороны если взять Хэш массив, опять таки объект, то опять таки имеем массив объектов, правда с "именованными" ключами.
Вопрос: нахрена козе баян? Ну а если серьезно, то где памяти больше утечет?

Сам-то как думаешь?
Все специфичные методы объектов Array, и Object находятся в прототипах.
то есть большая часть затраты памяти - напрямую связано с самим абстрактным типом данных.
ну, и вполне очевидно, что ассоциативный массив занимает больше памяти чем неассоциативный

А с чего памяти вообще утекать-то?

в яваскрипте нет массивов ;-)

tenshi, а кто сказал что они есть?
Kolyaj, я не имел в виду "утечки" как таковые, речь идет о тратах памяти.
Gvozd, так-то так, только есть у меня подозрения что ?!"маленькие"!? массивы выгоднее делать на основе Object, а не Array. Но с другой стороны, Array потомок Object, а значит каждое значение отягощено всей дребухой присущей как тому, так и другому в случае хранения числовых значений.
В общем нехрена не очевидно ;) Но линия такая тонкая :blink:
Вы меня просветлите, мож я че не так думаю :D

З.Ы. Согласитесь, тема более интересная чем: "напишите мне скрипт, а то я тут только сегодня зарегался" или "у меня на сайте, адрес которого я вам не дам, в коде ошибка которую я вам не покажу, в чем дело-то" :victory:

Тема неинтересная, вы не заметите разницы, особенно на ?!"маленьких"!? массивах.

Ну пока это поделки, да. Однако некоторые поделки вырастают до разных размеров :) Я предпочитаю, по возможности, подумать и написать помелче код. А если тонкости языка известны, то какие проблемы.
Вот в частности в PHP при использовании цикла for лучше написать ++$i, а не наоборот. В случае одного цикла это значения не имеет, а вот в случае навороченной CMS уже имеет, но никто особо не стремиться все это переписывать, хлопотно. Со сборщиком мусора там тоже тараканы есть. И тут тоже плюшки свои есть.
Подискутировать на тему высоких материй всегда интересно, можно даже ченить подчерпнуть :)
Насчет маленьких, не замечу, но она есть, однако при правильном использовании и при больших будет разница. Только вот неплохо было бы понять критерий слова "правильное" :)
А также не стоит забывать, что объем затраченной памяти обратно пропорционален производительности.

И в случае навороченной CMS не имеет, т.к. в процессе одного запроса все эти циклы запускаться не будут, а в одном случае один цикл, в другом -- другой. Поэтому разницы вы опять же не заметите. Даже если у вас внезапно появится цикл с перебором миллиона элементов (какие обычно делают в подобных тестах), то основное время будет тратиться на обработку самих элементов, а не на $i++, так что смена на ++$i опять же ничего не даст.


Я не понимаю, на чём вы пытаетесь память сэкономить, на именах свойств?

Array имеет в качестве прототипа экземпляр Array-а, который имеет в качестве прототипа экземпляр Object-а
поэтому "дребуха" хранится в уже и так существующих объектах, и никак не сказывается на размер новых объектов.

А вообще, это экономия на спичках.
Надо руководствоваться в данном случаен не затратами памяти, а уровнем абстракции, и использовать логически верный Абстрактный Тип Данных
К тому же, речь о производительности JS следует вести в контексте конкретных браузеров.
Внутри них возможны различные реализации.

Экономя память поднимается производительность. На рациональном использовании того что лучше подходит для решения тех или иных задач.
Не забывайте, Вы работаете с объектами и значит вы имеете дело с указателями ссылающимися на другие указатели, а данные разбросаны по памяти. Чем больше объект с которым вы работаете, тем больше фрагментированна память. Ну и пошли поехали. Каждая реализация интерпритатора: JScript, БелкаРыба да и хер как там они называются могут оптимизировать работу с ней, но могут этого и не делать.
Вам ASM известен, хоть поверхностно? Если да, то должны понять о чем я и к чему все это.

Да, только указатели копируются в зависимости от свойств и методов родителя, а в остальном все прекрасно. Если во всех движках реализация иная и более грамотная - поправте меня!

Конечно! Кто бы спорил, только спичек этих у меня полная коробка :) Да и 2,5 Га оперативы.


Да, именно к этому разговор и веду. Мож кто копался, ковырял, что скажет интересное.
Нет и небыло у меня идеи слово "Жопа" писать короче :)

слова вроде все знакомые, а общий смысл фразы остался для меня в тайне.
То есть у вас есть реальный проект на котором есть такая проблема?
Если да, то и изучайте на ее примере.
может узкое место вообще не там, где вы его видите.
а в применении к абстрактной задаче, вы занимаетесь фигней.
погуглить слабо?
есть набор универсальных JS-тестов, и результатов к ним для разных браузеров.
но там только скорость замеряется
как называется - не помню.гуглите

А что тут такого тайного? Если есть родитель, то потомок должен унаследовать все свойства и методы: скопировать ссылки на них. При более грамотной реализации этого можно не делать, а скопировать только указатель на объект и там уже подхватывать ссылки на общие свойства и методы, но этот вариант экономя память создает ряд других проблем и довольно серьезных.

А этот бред я слышу постоянно, вы видимо в школе не учились и институтов не кончали коль так заявляете :)

Нет

Спасибо, я догадываюсь и сам. А по скорости можно судить и об объеме памяти и о реализации интерпретатора, все конечно зависит от контекста самого теста.

Лично для себя, по своей натуре, в итоге я разберусь во всем. А остальной народ? Я думаю найдутся желающие почитать про идеи оптимального программирования. Каждый язык богат своими фишками, только о них мало кто знает и редко кто пользуется.
Что сейчас для веб девелопера значат слова "указатель", "приведение типа", да ровным счетом ничего. Там же и проблемы динамических массивов и длинные прыжки по памяти, о, и типы адресации.
С дальнейшим повышением уровня абстракции молодежь будет джина из коробки вызывать :) К этому и идем.
В общем ладно, грустно все это. За сим и откланиваюсь.

Если бы вы внимательнее читали справку по JS, и вообще бы больше уделили внимания основам, то вы бы знали, что только ссылка на объект-родитель, у потомка и есть.
Это называется механизмом прототипного наследования.
У любого объекта есть объект-прототип. Его Родитель, так сказать.
объект хранит только ссылку на объект-родитель. причем в скрытом свойстве.
Если у объекта нету какого-то свойства, то он ищет его у своего прототипа.
Если у того его также нет, то он ищет его у своего прототипа.

Я думаю, вам стоит меньше кричать, про то, кому писать на форрме, а кому нет, а больше читать справку на нашем сайте.
ведь вы сами не подходите под ваше же определение:
Мое мнение никак не связано с моим формальным уровнем образования.
И если уж все вокруг несут бред, то вы либо пророк, либо сами несете бред.
А, я вам скажу, исходя из своей жизненной школы, что не всякая абстрактная задача полезна.
Если абстрактная задача имеет неполное условие, то она бесполезна, при условии, что различные дополнительные условия, могут дать ей различный ответ.
Ваша задача именно такая. Её следует рассматривать при больших уточнениях.


Для быдло-кодеров.
для начинающих.
Подавляющее большинство профессионалов, знает эти понятия.
Но, более того, я вам скажу, что эти понятия имею гораздо меньшую ценность для интерпретируемых языков(особенно с кучей различных реализацией), у которых слабая типизация.
а именно на этих языках и строится веб.

Веб - это не та область, где из вариантов следует выбирать более производительный.
Пользователь не всегда оценит, или даже заметит
Но, базовые знания о производительности надо иметь.
чтобы не писать архи-непроизводительных вариантов.
например один из базовых принципов для PHP (и многих других интерпретируемых языков), то, что любой самый быстрый алгоритм написанный на самом языке заведомо медленнее, чем вызов стандартной аналогичного действия функции.

Но в некоторых реализациях открытом.

O - потребление памяти пустым объектом
n - число объектов
On - потребление памяти всеми объектами без учёта ключей
o - среднее потребление памяти одним ключом
k - общее число ключей
ok - потребление памяти всеми ключами
On+ok - общее потребление памяти заданной структурой, без учёта хранимой в ней информации

сравним 2 структуры:
1. массив объектов
2. объект массивов
k в обоих случаях одинаковое, но o во втором случае несколько меньше за счёт числовых индексов
n во втором случае пропорционально числу свойств, а в первом - глубине массива.

коэффициэнты можно посчитать, но и так видно, что как правило вторая стратегия несёт в себе меньше накладных расходов.

А если в объекте тоже числовые ключи используются? Собственно так оно и есть, если мы говорим о замене массива объектом.

массив - это объект с числовыми индексами

Массив в терминологии JavaScript -- это объект, порождаемый конструктором Array.

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

Да и еще пару тройку ссылок на объекты своих свойств и методов, ктоторые тоже хранят ссылки ...

А на каком основании построены сие доводы? Так, пофлудить? Не совершает ошибок только тот, кто ничего не делает.

Полезна всякая. Большинство задач с множеством неизвестных решаются итерациями из которых строятся предварительные выводы. Таким образом, добавив еще неизвестных не придется ломать голову над всей задачей, а всего лишь изменить или дополнить некоторые ее компоненты. Наша жизнь сама по себе абстрактная задача, уже молчу про детали.

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

Array это не только ценный мех, но еще и наследник от Object. Хотя меня уже сомнения одолели :)