Помогите...
Тормозит кусок кода, который вроде как не участвует в работе...
Ссылка: Карта неба, черновик
При попытке перетащить карту мышкой, заметно сильное торможение прорисовки.

Вот кусок сбойного кода:

Функция Draw_map вызывается многократно при изменении координат мыши и перерисовывает карту.
Тормоза вызывают те две строки, которые читают данные из формы.
Если их закомментировать и вместо них активировать следующие две строчки (где "=650"), то тормоза исчезают - можете поверить на слово, что скорость будет такая же, как здесь (в этой версии присваивается просто число из переменной, никакого считывания из формы нет).

Да, считывание из формы сильно тормозит обработку, если постоянно вызывается... 
Для этого я и поставил alert, чтобы было видно, что этот кусок отрабатывает только один раз, при загрузке страницы, а потом он уже не работает!

В чём может быть дело? 


Это сообщение отредактировал(а) kuksha - 23.3.2015, 22:19

Ау!!! 
Есть соображения?   

Посмотрел код. Много букв, так что высказаться могу только, исходя из общего впечатления. Сам код этой функции очень длинный и в нем столько вызовов типа document.###.value, что и не сосчитать, кроме того там есть функции draw###, в которых тоже содержатся подобные же вызовы и сколько раз они вызываются в процессе прорисовки карты - об этом можно только догадываться. И вот в связи с  этим, если ты предполагаешь (вполне резонно, кстати), что тормоза обусловлены обращением к элементам формы при прорисовке, то мне не очень понятно, почему ты грешишь именно на эти две строчки, а насчет всего остального уверен, что там все нормально?

И ещеЯ правильно понял, ты в процессе прорисовки еще и запрос на сервер отправляешь?  

Указанный код переделал - поставил ParseInt:

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

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

Оптимизация данного кода - отдельная песня. (запрос на сервер отправляется только один раз, там всё нормально, просто функция заведует не только прорисовкой карты, не в этом дело.)

Да, что-то сделано не лучшим образом. 
Но, вопрос был не в оптимальности остальных участков, а в том, как изолированный участок кода мог влиять на работу, в то время, как он сам НЕ РАБОТАЛ (в процессе перемещения карты мышкой он не был задействован).

Это сообщение отредактировал(а) kuksha - 25.3.2015, 16:23

Ну ты же понимаешь, что если код при прорисовке не выполняется, то повлиять на производительность прорисовки он не может в принципе? Возможно в процессе замены строк ты внес еще какие-то изменения, но забыл об этом. 

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

Никак.

Вот какое соображение, хотя это бред с точки зрения эффективности интерпретаторов кода...
Не может ли в каких-то случаях происходить так, что браузерный интерпретатор JavaScript анализирует участок, который он должен перепрыгнуть, поскольку условие его выполнения не выполнено?
То есть код НЕ ВЫПОЛНЯЕТСЯ, но тем не менее АНАЛИЗИРУЕТСЯ?

Добавлено @ 16:47
diadiavova, я то понимаю, что это бред, но я в любое время могу продемонстрировать как этот бред работает, если есть желание... И поверьте, я эту замену делал делал не один раз и показывал людям вживую, прежде чем написать сюда.
именно абсурдность и была главной причиной вопроса.

Лучше не касаться эффективности других участков кода.

Это сообщение отредактировал(а) kuksha - 25.3.2015, 16:58

Думаю, это крайне маловероятно. 

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

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

Да и у меня не осталось мыслей, просто тупо смотрел как это происходит. Коллеги тоже покрутили пальцем у виска и молча ушли. 
Поэтому и написал сюда... 
А разница в скорости прорисовки "на глазок" была слишком явная...
Ладно, нет так нет.

kuksha, кстати, в том фрагменте, который ты представил здесь, есть отличие от того, что я нашел на сайте. Здесь ты не преобразовал значение, полученное из селекта в число. Может дело в этом?

diadiavova, я про всё это уже писал выше... посмотрите просто...

Короче вот ещё раз:
Это первый вариант, который тормозит: http://kosmoved.ru/nebo_segodnya_geo_24.php
Его код:


Это второй вариант, который без тормозов: http://kosmoved.ru/nebo_segodnya_geo_25.php
И соответственно его код.


var Pervy_prohod=0 - определено в начале файла в качестве глобальной переменной.

Делал копированием, так что идентичность остального кода - полная.
Обратите внимание, что alert появляется только при загрузке. А должен бы постоянно мелькать, если эти строки реально отрабатываются и виноваты именно они. Но, нет, всё правильно - алерт появляется только один раз, как и заказывали...

Фиг с ними, с тормозами и с неправильным типом данных в первом варианте! 
Вопрос - каким боком этот кусок кода вообще на что-то влияет при последующей работе, когда права  на это у него нет???

Начало кода в исходнике draw_map_24022015.js и draw_map_25022015.js - строка номер 2869.

Может у кого-то всё-же хватит терпения вникнуть и ткнуть меня носом куда следует... сам я не вижу...

Это сообщение отредактировал(а) kuksha - 25.3.2015, 22:11

Да собственно я озвучил проблему. Разница как раз в типе данных и состоит. Ну проверь как будет работать код, если ты присвоишь переменной строковые значения.Я думаю, так же, как и при запросе из формы, поскольку он возвращает строку. Ведь ты же не просто присваиваешь значение переменным, а потом его используешь. Используешь как число. Например делишь на два. Что по-твоему должно получиться при делении строки на два? С точки зрения статического языка должно вывалиться исключение, а динамический язык сначала ищет способ разрешить противоречие, а это связано и с затратами ресурсов на поиски и с преобразованием, которое надо выполнять всякий раз, когда ты пытаешься выполнить арифметическую операцию над строкой. Вот и вся разгадка.

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

Если бы не было условия  if (Pervy_prohod==0) и это считывание из формы выполнялось каждый раз - вопросов бы не было - виноват тип данных и точка... но ведь всё не так!

Ты условие if (Pervy_prohod==0) видишь?
Видишь, что при первом проходе оно выполняется, в результате чего Pervy_prohod делается равным 1?
Ты же понимаешь, что поскольку Pervy_prohod - глобальная переменная, то больше это условие не выполнится при последующих вызовах функции по ходу работы, пока страницу не перезагрузим? А если так, то и присвоений переменным RazmerKartyX RazmerKartyY больше не будет. 
НЕ СРАБОТАЮТ БОЛЬШЕ ЭТИ СТРОКИ по мере перетаскивания карты. Они отрабатывают только ОДИН раз - при загрузке страницы, когда Pervy_prohod=0.
И то, что alert больше не появляется по ходу прорисовки, как раз именно об этом и говорит - не попадает интерпретатор больше в этот кусок кода!
НЕ ПОПАДАЕТ! 
и неважно какой там тип данных и сколько ошибок - совершенно по-барабану! 

Так откуда появляются тормоза из-за нерабочего куска кода? Да будь там что угодно - раз оно не отрабатывает, оно и не может влиять на скорость!

Я не знаю как ещё объяснить...

Это сообщение отредактировал(а) kuksha - 25.3.2015, 22:52

Объясняю еще раз: тормоза происходят не из-за присвоения. Вовсе не этот участок кода их вызывает. Тормоза вызываются теми участками, где ты пытаешься над строкой выполнять арифметические операции. Переменные RazmerKartyX и RazmerKartyY ты используешь за пределами блока с условием? Вот там и ищи проблему. Все очень просто операциястоит дорого, а операция практически ничего не стоит. Таким образом, от того, что ты присвоишь упомянутым переменным ( 650 или "650") зависит насколько быстро будет выполняться деление, которое у тебя прописано независимо от того, какой это проход, хоть первый, хоть второй, хоть задний. 

Да нет, вот как раз-таки не пофиг.  

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

Всё, вот теперь дошло!!!!   
Извини, что из себя вышел.

Я действительно не учёл, что поскольку приведения типа не было, то и дальше в арифметических операциях используется строка , а не число... зациклился - объяснения читал и понимал, но применил их не дальше этих двух строк... вот я тормоз... 

Спасибо огромное за терпение!   

Уфффф... полегчало - я уж думал у меня крыша едет...

Ничего, бывает