Знаете, смотрел немного, хотя и плаваю в понимании результатов EXPLAIN. Однако...
1) Если давать только вложенный запрос, без внешнего, то результаты одинаковы, как и план выполнения.
2) Если же завернуть как в условиях вопроса, то EXPLAIN у них очень разный. Там где переменная - появляется полное сканирование во внешнем запросе. Но главное - запрос виснет совсем, а не просто долго выполняется. Статус запроса на сервере - Sending data.
3) Опять-таки, если убрать условие по dt, то оба запроса выполняются нормально.
Честно говоря, непонятно отличие переменной заданной через SET и переданной в процедуру с точки зрения возможности её изменения. Ну пусть это не дает оптимизировать план выполнения или кэшировать запрос. Но неадекватно вешать? Таблица-то небольшая, не более 50 тыс. строк.
Спасибо, погляжу.
Пока разбираюсь с clintberry.com/2013/angular-js-websocket-service
Если к этому добавить обработку самостоятельно отправленных сообщений от сервера, то может быть получится то что нужно...
Neyury: Разумеется, можно подключить стили CSS-файлом. А вот насчёт включения их в сам SVG - есть сомнения, но категорически "нет" не скажу, надо смотреть стандарт.
Если не нравится загромождение кода, то можно пользоваться инклюдами. Либо серверными, либо клиентскими. Зависит от того, какие фреймворки и шаблонизаторы используете.
Например в случае использования ангуляра, наверное можно использовать ng-include и убить сразу двух зайцев. У вас будут отдельные мальенькие HTML-файлы (не полноценные, только с кучком DOM, содержащим SVG-вставку). А при сборке странице, ангуляр сам распихает эти вставки в дерево и к ним применятся стили из CSS-файла, который прописан для главной HTML-страницы.
Возможно, опытные ангулярщики возразят. Не претендую, поскольку недавно за него взялся.
Neyury: Если используете первый вариант, то файл как таковой перестаёт существовать. Его SVG-код встраивается в HTML.
Разумеется, когда мы рассматриваем второй случай (вставка в качестве img src или background какого-то html-элемента), то можно использовать еще и data-url: jsfiddle.net/6WAtQ
Но всё это не дает доступа к SVG.
Есть более сложный (возможно, слабо кроссбраузерный) способ. Использовать для внедрения теги object и т.п. Тогда файл svg будет отдельно и доступ к нему будет некоторым способом.
См.: stackoverflow.com/questions/8102528/how-do-you-acc...
SVG можно размещать как inline-кодом (т.е. SVG-код прямо в дерево HTML), так и как обычное изображение. Первый случай в примере, который я нагуглил. При этом вам доступна возможность управлять стилями SVG-элементов через CSS (Да, там другие свойства, а некоторые просто иначе называются). Кроме того, можно работать и javascript-ом с элементами SVG.
А во втором случае вы получаете просто изображение. И тут для hover вам уже надо делать по-старинке - спрайтами в бэкграунде, например.
Насчёт точек с запятой я в курсе, но поскольку я пишу в основном на других языках, привычка.
Получается список списков в моём варианте равносильно списку указателей на списки. Тогда, разумеется, когда я меняю элемент в одном из вложенных, меняется во всех других списках тоже.
Но вот это "В первой строчке вы создали список из 10 ссылок на один объект списка." непонятно.
Если так, то [0]*10 должен создавать список с указателями на один объект и меняться должны все.
Однако же нет. Создается список с десятью разными объектами.
А вот уже [[0]*10]*10 создет список с указателями на список со значениями.
Разве не так?
copal: Но дело в том, что это происходит не сразу, а после некоторого количества вызовов. Как-будто некий "быстрый буфер" заполняется за несколько раз и перед следующим вызовом он должен очиститься, что и вызывает такие тормоза. Память?
Nipheris: Да, согласен. Очереди прекрасно ложились в основу взаимодействия цикла UI и обработки данных в LabVIEW- приложениях.
Здесь я не задумался об этом потому что producer один и consumer один. Кроме того, устройство подключено слейвом по RS485, поэтому его сообщения идут только в ответ на запросы приложения. Но буду и иметь ввиду! Больше спасибо!
Invoke-и я использовал, да. Но вот понимание, почему поток другой - не было. Буду внимательнее читать.
Дело еще в том, что у меня один из кастомных контролов (мнемосхема устройства) выполнена как WPF в ElementHost. Я всё думал на это. Но потом выяснилось что и для кастомных Windows Forms контролов то же самое...
Спасибо. Не дочитал я значит. Собственно парсинг потока байт и формирование различных событий более высокого уровня для GUI сделаны уже сейчас. Либо устройство присылает в порт слово состояние, собственно, индикаторы я по нему и переключаю. Либо сыпятся асинхронные события самого устройства. Они тоже обрабатываются в классе менеджера порта, а в презентер уже улетает событие "Произошло то-то и то-то".
Поток GUI дергается не по приходу пары байт, а по факту прихода логического сообщения. По факту - по приходу байта завершения посылки.
MiiNiPaa: Да, как-то сразу не дошло, что компилятор-то же в курсе про тип, а значит и арифметику соответственно делает на стадии компиляции, а не в рантайме.
MiiNiPaa: Под "просто создал" я имел ввиду не malloc(), а обычное объявление указателя и затем присваивание ему адреса другой переменной. Вопрос не про удаление в данном случае, а про то, где хранится "размер ячейки" (т.е. тип перменной), на которую ссылается указатель. Ведь арифметика указателей работает правильно. Значит где-то лежит. А значит указатель в памяти занимает больше чем 32 бита.
Хорошо, это в случае с областью, когда указатель пришёл из malloc().
А если я просто создал указатель? Как арифметика указателей знает где хранится размер ячейки?
Значит в памяти перменная указателя должна занимать больше места, чем просто под адрес ячейки. Получается, так?
Вот это странно. Я стандарт не досконально читал, но насколько мне известно - нет там никаких управляющих символов. CRLF - это уже из области прикладного протокола. Например, в HTTP отделяет заголовки от тела. В моём случае данные - бинарные. Вводить управляющий символ - не хочется. Поэтому и пытаюсь понять - на основе самих пакетов TCP можно ли понять - начало/конец передачи в рамках одного соединения...
Дмитрий Энтелис: Погляжу socket.io. Но у меня вопрос скорее абстрактный, чем именно про NodeJS. Вопрос собственно к тому, что при передаче шифрованных данных надо понимать - кончился блок или нет. Или здавать размеры блока отдельно. Видимо надо изучить детали реализации SSL и не смешивать несколько уровней в один.
1) Если давать только вложенный запрос, без внешнего, то результаты одинаковы, как и план выполнения.
2) Если же завернуть как в условиях вопроса, то EXPLAIN у них очень разный. Там где переменная - появляется полное сканирование во внешнем запросе. Но главное - запрос виснет совсем, а не просто долго выполняется. Статус запроса на сервере - Sending data.
3) Опять-таки, если убрать условие по dt, то оба запроса выполняются нормально.
Честно говоря, непонятно отличие переменной заданной через SET и переданной в процедуру с точки зрения возможности её изменения. Ну пусть это не дает оптимизировать план выполнения или кэшировать запрос. Но неадекватно вешать? Таблица-то небольшая, не более 50 тыс. строк.