Тестовое задание.

[samana]

Выше было мнение, что в цикле for (i=0;i<arr.lenght;i++):

При обращении к length она и не считается каждый раз.

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

[FlashRus]

Длина масива считается при его изменении, а при обращении к Array#length ничего пересчитываться не будет, т.к. уже всё посчитано.
Было бы действительно удивительно, если бы было иначе, т.к. это краней не оптимальный расход ресурсов.

[Tails]

Длина массива не пересчитывается при изменений, она считается при обращений к length, каждый раз. Этому есть вполне разумное объяснение - не всегда при добавлений элементов в массив, его длину нужно пересчитывать. Это был-бы ещё более не оптимальный расход ресурсов.

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

Такой вывод я сделал исходя из теста с частым обращением к length. Длина пересчитывается с каждым обращением. Остальное - догадки.

[FlashRus]

Длина массива не пересчитывается при изменений, она считается при обращений к length, каждый раз. Этому есть вполне разумное объяснение - не всегда при добавлений элементов в массив, его длину нужно пересчитывать. Это был-бы ещё более не оптимальный расход ресурсов.

На мой взгляд гораздо разумнее инкриментировать некую переменню при добавлении элементов, чем нежели при обращении к length пересчитывать элементы.
_length ++ разве является расходной операцией?

Мои догадки хорошо иллюстрированы листигом из тамарина здесь.

[Tails]

Значит я ошибся с выводом.
А причина тормозов при обращений к длине в цикле - двойной вызов функций * на количество итераций. Всяко благоразумнее будет перед выполнением цикла занести длину в отдельную локальную переменную.

[FlashRus]

Всяко благоразумнее будет перед выполнением цикла занести длину в отдельную локальную переменную.

Надо потестить это дело.
А что касается прошлого вопроса, вот результаты моих тестов:

Длина, начальный момент времени, конечный и дельта.

0 => 987, 987, 0
1000 => 987, 987, 0
10000000 => 1929, 1929, 0

addEventListener(MouseEvent.CLICK, clickHandler)
var arr:Array = [];
var currLength:int;
var t0:int;
var t1:int;
var i:int;
 
function clickHandler(e:MouseEvent):void {
	calculateAndAppendData()	
	for (i = 0; i < 1000; i++) {
		arr.push(Math.random())
	}
	calculateAndAppendData();
	arr = [];
	for (i = 0; i < 10000000; i++) {
		arr.push(Math.random())
	}
	calculateAndAppendData();
}
 
function calculateAndAppendData():void {
	t0 = getTimer();
	currLength = arr.length;
	t1 = getTimer();
	tf.appendText(currLength + " => " + t0 + ", " + t1 + ", " + (t1 - t0) + "\n");
}

Добавлено через 17 минут

Всяко благоразумнее будет перед выполнением цикла занести длину в отдельную локальную переменную.

По результатам теста благорзаумнее на 4мс при миллионной длине массива.

(i = 0; i < arr.length; i++) => 1032, 1048, 16
(i = 0; i < localLength; i++) => 1048, 1060, 12

	t0 = getTimer();
	for (i = 0; i < arr.length; i++) {
		arr[i]
	}
	t1 = getTimer();
	tf.appendText("(i = 0; i < arr.length; i++) => " + t0 + ", " + t1 + ", " + (t1 - t0) + "\n");
 
	t0 = getTimer();
	var localLength:int = arr.length;
	for (i = 0; i < localLength; i++) {
		arr[i]
	}
	t1 = getTimer();
	tf.appendText("(i = 0; i < localLength; i++) => " + t0 + ", " + t1 + ", " + (t1 - t0) + "\n");

[Tails]

Вы используете переменные уровня класса, доступ к ним более медленный, по сравнению с доступом к переменным метода/функций. Это может сглаживать результаты.

Вот мои результаты тестов:
Array:

localLength: 200ms
arr.length: 333ms

Миллион итераций, разница скорости выполнения: 1.6

Vector (no fixed):

localLength: 88ms
arr.length: 111ms

10 миллионов итераций, разница скорости выполнения: 1.2

Vector (fixed):

localLength: 88ms
arr.length: 113ms

10 миллионов итераций, разница скорости выполнения: 1.2

import flash.events.MouseEvent;
 
 
stage.addEventListener(MouseEvent.CLICK, clickHandler)
 
 
function clickHandler(e:MouseEvent):void {
	const itterations:uint		= 1000000;
	//const arr:Array				= new Array(itterations);
	const arr:Array				= new Array(itterations);
	var i:uint;
	var t1:uint;
	var t2:uint;
 
	t1							= getTimer();
	for(i = 0; i < itterations; i ++){
		arr[i];
	}
	t2							= getTimer();
	trace('localLength: '+ (t2 - t1) + 'ms');
 
	t1							= getTimer();
	for(i = 0; i < arr.length; i ++){
		arr[i];
	}
	t2							= getTimer();
	trace('arr.length: '+ (t2 - t1) + 'ms');
}

[FlashRus]

Компиляция в релизе была?

Вы используете переменные уровня класса, доступ к ним более медленный, по сравнению с доступом к переменным метода/функций. Это может сглаживать результаты.

Не подумал об этом. Всё верно, скорость выше примерно в два раза.

[Tails]

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

[Hauts]

Относительно задания — там явно прописано, что должны быть кнопки "+" и "-", у автора это "add" и "minus" (еще и total есть). Это мелочь, конечно, но всё-таки, мне кажется, что нужно подходить очень внимательно к подобным вещам.

По коду:

private var planets:Vector.<Planet>;

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

private var _planets:Vector.<Planet>;

"onClick", "onMove" и т.д. я бы переписал на "mouseClickHandler" или типа того. Хотя это не ошибка, да.

Про "for (var i:int = 0; i < planets.length; i++)" уже говорили.

В Universe свойство graphics вполне можно закэшировать.


Думаю, что вполне неплохо выполненное тестовое задание. Но само задание так себе, не показательно, как мне кажется.

Добавлено через 2 минуты
А, и еще:

Причина: не оптимизированный код.

Мне кажется, это довольно-таки, нехорошо в таком формате отвечать на выполненные тестовые задания. В хорошем случае я (как соискатель) ожидаю получить нормальный развёрнутый ответ.