Один сложный запрос по сравнению с Несколькими простыми запросами

Исправлено. Код работает, движение оси Y отключено.

console.log("Desktop");
if (WEBGL.isWebGLAvailable() === false) {
	document.body.appendChild(WEBGL.getWebGLErrorMessage());
}
var SEPARATION = 100,
	AMOUNTX = 50,
	AMOUNTY = 50;
var container;
var camera, scene, renderer, controls;
var particles, count = 0;
var mouseX = 0,
	mouseY = 0;
var windowHalfX = window.innerWidth / 2;
var windowHalfY = window.innerHeight / 2;

// var isMobile = isOSMobile();
var isMobile = true;

init();
animate();

function init() {
	container = document.createElement('div');
	document.body.appendChild(container);
	camera = new THREE.PerspectiveCamera(75, window.innerWidth /
		window.innerHeight, 1, 10000);
	if (isMobile) {
		controls = new THREE.DeviceOrientationControls(camera);
	}
	camera.position.z = 1000;
	scene = new THREE.Scene();
	//
	var numParticles = AMOUNTX * AMOUNTY;
	var positions = new Float32Array(numParticles * 3);
	var scales = new Float32Array(numParticles);
	var i = 0,
		j = 0;
	for (var ix = 0; ix < AMOUNTX; ix++) {
		for (var iy = 0; iy < AMOUNTY; iy++) {
			positions[i] = ix * SEPARATION - ((AMOUNTX *
				SEPARATION) / 2); // x
			positions[i + 1] = 0; // y
			positions[i + 2] = iy * SEPARATION - ((AMOUNTY *
				SEPARATION) / 2); // z
			scales[j] = 1;
			i += 3;
			j++;
		}
	}
	var geometry = new THREE.BufferGeometry();
	geometry.addAttribute('position', new THREE.BufferAttribute(
		positions, 3));
	geometry.addAttribute('scale', new THREE.BufferAttribute(scales,
		1));
	var material = new THREE.ShaderMaterial({
		uniforms: {
			color: {
				value: new THREE.Color(isMobile ? 0xffffff : 0x8D8D8F)
			},
		},
		vertexShader: document.getElementById(
			'vertexshader').textContent,
		fragmentShader: document.getElementById(
			'fragmentshader').textContent
	});

	particles = new THREE.Points(geometry, material);
	scene.add(particles);

	renderer = new THREE.WebGLRenderer({
		antialias: true
	});
	renderer.setPixelRatio(window.devicePixelRatio);
	renderer.setSize(window.innerWidth, window.innerHeight);
	container.appendChild(renderer.domElement);
	document.addEventListener('mousemove', onDocumentMouseMove,
		false);
	window.addEventListener('resize', onWindowResize, false);
	if (isMobile) {
		window.addEventListener("deviceorientation", handleOrientation, true);
	}
}

function handleOrientation(e) {
	var absolute = e.absolute;
	var alpha = e.alpha;// x -90 ... 90
	var beta = e.beta;// y 180 ... 0
	var gamma = e.gamma;// x -90 ... 90

	mouseX = -5 * windowHalfX * (gamma / 90);
	//mouseY = -windowHalfY * ((beta - 90) / 90);

	// console.log(mouseX.toFixed(2), ' x ', mouseY.toFixed(2));
}

function onWindowResize() {
	windowHalfX = window.innerWidth / 2;
	windowHalfY = window.innerHeight / 2;
	camera.aspect = window.innerWidth / window.innerHeight;
	camera.updateProjectionMatrix();
	renderer.setSize(window.innerWidth, window.innerHeight);
}
//
function onDocumentMouseMove(event) {
	mouseX = event.clientX - windowHalfX;
	mouseY = event.clientY - windowHalfY;
}

//
function animate() {
	requestAnimationFrame(animate);
	render();
	if (isMobile) {
		controls.update();
	}
}

function render() {
	camera.position.x += (mouseX - camera.position.x) * .05;
	if(isMobile) {
		camera.position.y = 550;
	} else {
		camera.position.y += (-mouseY - camera.position.y) * .05;
	}
	camera.lookAt(scene.position);
	var positions = particles.geometry.attributes.position.array;
	var scales = particles.geometry.attributes.scale.array;
	var i = 0,
		j = 0;
	for (var ix = 0; ix < AMOUNTX; ix++) {
		for (var iy = 0; iy < AMOUNTY; iy++) {
			positions[i + 1] = (Math.sin((ix + count) * 0.3) * 50) +
				(Math.sin((iy + count) * 0.5) * 50);
			scales[j] = (Math.sin((ix + count) * 0.3) + 1) * 8 +
				(Math.sin((iy + count) * 0.5) + 1) * 8;
			i += 3;
			j++;
		}
	}
	particles.geometry.attributes.position.needsUpdate = true;
	particles.geometry.attributes.scale.needsUpdate = true;
	renderer.render(scene, camera);
	count += 0.1;
}

function isOSMobile() {
	var userAgent = navigator.userAgent || navigator.vendor || window.opera;

	if (/android/i.test(userAgent)) {
		return true;
	}
	if (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream) {
		return true;
	}

	return false;
}

19
задан Lieven Cardoen 26 March 2009 в 09:00
поделиться

3 ответа

Общее эмпирическое правило здесь - то, что распространения в прямом и обратном направлениях сервера являются дорогими (относительно того, сколько времени типичный запрос берет), таким образом, руководящий принцип - то, что Вы хотите минимизировать их. В основном соединение each one-many потенциально умножит Ваш набор результатов так способ, которым я приближаюсь, это должно продолжать присоединяться, пока набор результатов не становится слишком большим, или время выполнения запросов становится слишком длинным (примерно 1-5 секунд обычно).

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

Иногда стоит сохранить определенные относительно постоянные данные в памяти (информация о стране, например) или сделать их как отдельно запрос, но это, по моему опыту, довольно необычно.

Намного более распространенный должен согласовать системы с ужасной производительностью в значительной степени благодаря выполнению отдельных запросов (особенно коррелируемые запросы) вместо соединений.

15
ответ дан 30 November 2019 в 04:25
поделиться

От инстинктивного чувства я сказал бы:

Пойдите с простым путем, пока нет никакой доказанной причины оптимизировать для производительности. Иначе я поместил бы "сложные объекты и запрос" подход в корзине преждевременной оптимизации.

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

4
ответ дан 30 November 2019 в 04:25
поделиться

Я не думаю, что любой вариант на самом деле лучше. Это зависит от Вашего специализированного, архитектуры, использовал DBMS и другие факторы.

Например, мы использовали несколько простых запросов с в нашем отдельном решении. Но когда мы развили наш продукт к легкому доступному для Интернета решению, мы обнаружили, что наша платформа сделала огромное количество запроса и который уничтожил причину производительности сетевой задержки. Таким образом, мы достаточно переделали нашу платформу для использования агрегированных сложных запросов. Между тем мы все еще поддержали наше отдельное решение и переместились от Света Oracle до Derby Apache. И еще раз мы нашли, что некоторые наши новые сложные запросы должны быть упрощены, поскольку Derby выполнял их слишком долго.

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

7
ответ дан 30 November 2019 в 04:25
поделиться
Другие вопросы по тегам:

Похожие вопросы: