Taran
Ещё бы понятия не называть вещами.

IK mode on

Такие понятия как "предметы" , "вещи" - не синонимичны, если рассматривать их гносеологический аспект.

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

IK mode off

ssa

Grin
По кодировке может и ошибаюсь, но вроде на глаз определил правильно.

Речь не про правильность определения кодировки, а про называние вещей чужими именами. Юникод с кодировками и JSON - разные вещи.

2SSA
Ок, я не компетентен. Пережеву.

2ALL
Всем откликнувшимся, спасибо.

Grin

ssa

Grin
По кодировке может и ошибаюсь, но вроде на глаз определил правильно.

Речь не про правильность определения кодировки, а про называние вещей чужими именами. Юникод с кодировками и JSON - разные вещи.

2SSA
Ок, я не компетентен. Пережеву.

Увы, но пережевать и переживать - тоже разные вещи.
Лучше бы рассказали о тестировании предложенных вариантов.
Обзовём их так: вариант Игоря - вариант первый, вариант Leonid - вариант второй и мой вариант - вариант третий.
В моих тестах вариант второй совсем не "чуток", то есть в несколько раз , быстрее варианта первого. Но он создает и потом уничтожает файл.
Могу предложить вариант без возни с файлами, но он чуть медленнее варианта второго.
Вариант первый при увеличении входной строки в 2 раза работает в 10 медленнее, варианты второй и третий - в два. То есть зависимость времени работы функции от размера входной строки линейная у второго и третьего вариантов и далеко не линейная в первом варианте.
Показывать?

2SSA
Пока не до того...
Обязательно отпишусь.

Результат теста:

Входящий json 2mb 238kb

Первичный вариант - 1237 сек
Вариант от Leonid - 3 сек
Вариант Симплы требует перепиливания классов парсинга json

Всем спасибо за помощь.

ssa
Обзовём их так: вариант Игоря - вариант первый, вариант Leonid - вариант второй и мой вариант - вариант третий.

Предлагаю как идею (реализовывать и проверять сейчас некогда) четвертый вариант:
1) с помощью ALINES() с разделителем '\' исходная строка (быстро) разбивается на подстроки, каждая из которых начинается с символа юникода, за которым могут идти обычные символы:
u0434ABCD
u0432
u0438

2) затем обрабатываются элементы полученного массива - юникод-символ извлекается особо, остальная часть подстроки "приклеивается" без изменений.

Думаю, что этот вариант должен показывать результат, соизмеримый с "файловым" (плюс/минус). А в случае, если количество юникод-символов в общем количестве символов строки мало или вообще отсутствует, то и быть лучшим.



Исправлено 2 раз(а). Последнее : akvvohinc, 27.12.19 16:44

akvvohinc
Предлагаю как идею четвертый вариант:
1) с помощью ALINES() с разделителем '\' исходная строка (быстро) разбивается на подстроки, каждая из которых начинается с символа юникода, за которым могут идти обычные символы:
u0434ABCD
u0432
u0438

2) затем обрабатываются элементы полученного массива - юникод-символ извлекается особо, остальная часть подстроки "приклеивается" без изменений.

Думаю, что этот вариант должен показывать результат, соизмеримый с "файловым" (плюс/минус). А в случае, если количество юникод-символов в общем количестве символов строки мало или вообще отсутствует, то и быть лучшим.

Полностью реализовать и проверить уже нет времени, но вот скорость парсинга уже проверил, шустренько.

ssa
но вот скорость парсинга уже проверил, шустренько.

Ну, так парсинг же не на фоксе написан.
Я взял для примера файл размером около 20 мегов - не успел и глазом моргнуть...

"Склейка" будет медленной. Проще сначала распарсить json без декодирования, а потом уже декодировать "строки" - надеясь что там просто очень много мелких элементов, а не по целой главе "Война и Мир" внутри одного свойства.
Ну или не писать всё это на фоксе На старом добром си можно обойтись без миллионов вырезаний/склеек строк. А так то можно взять и систему где просто уже реализована достаточно эффективная десериализация json-ов.

Igor Korolyov
"Склейка" будет медленной. Проще сначала распарсить json без декодирования, а потом уже декодировать "строки"

Тут речь изначально ведется не о "джейсоне" (просто так тема названа ), а о строке, содержащей Unicode Escape Sequence.

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



Исправлено 1 раз(а). Последнее : akvvohinc, 28.12.19 22:32

Каким образом "за один раз" можно из массива собрать обратно строку, да ещё и позаменять в каждом элемента массива первые символы на декодированную букву - опять же без склейки строк (пусть и не таких больших, возможно).

Igor Korolyov
Каким образом "за один раз" можно из массива собрать обратно строку, да ещё и позаменять в каждом элемента массива первые символы на декодированную букву - опять же без склейки строк

Но я и не писал такого.

Я написал, что в отличие от предыдущих вариантов, где выходная строка формируется посимвольно, в моем может быть иначе - если в некотором элементе массива окажется 1000 символов, то после обработки первого, юникодовского, остальные можно "приклеить" все за раз (одной командой):
а не по одному (в цикле):



Исправлено 1 раз(а). Последнее : akvvohinc, 31.12.19 17:00

() если что, то строки можно "склеивать" SYS(2600), получается гораздо быстрее.
Только надо самому резервировать память, прикидывать сколько ее надо, освобождать, и для больших файлов >2Г тоже надо буферизировать, на границах буфера писанину разводить.

of63
() если что, то строки можно "склеивать" SYS(2600), получается гораздо быстрее.

Это тонкий вопрос... Для САМОЙ этой функции потребуется выделять память под строку с которой функция работает - невозможно напрямую, не используя фоксовые прослойки для работы со строками загнать в память хоть 1 символ, хоть 100 - из кода на фоксе, естественно.

Да, SYS(2600) (и функцию выделения/освобождения памяти в куче, или в где-то там в ОС) оказалось достаточно, чтобы не лезть в Си и ассемблер при приеме файла недействительных паспортов (150млн записей по 10 цифр). Я их утрамбовывал в схему "1 паспорт - 1 бит", для чего потребовался STUFF, чтобы установить нужный бит в нужном байте строки. С этим STUFF вышло, что сутки-другие это копошится, с заменой этого STUFF на SYS(2600) принимается за 1-2 часа. Я раньше хвалился на эту тему. Полезная фишка в фоксе.

> Для САМОЙ этой функции потребуется выделять память под строку с которой функция работает - невозможно напрямую, не используя фоксовые прослойки для работы со строками загнать в память хоть 1 символ, хоть 100 - из кода на фоксе, естественно.

of63
Не понял в чем проблема, надеюсь пояснил выше... "Загнать в память" - это проблема в чем?...

чтение:
cRes = SYS(2600, nAddress, nLen)

cRes это фоксовая строка. Т.е. предположим у тебя есть какой-то блок данных в памяти (не важно как полученный и заполненный - пусть это будет Memory-mapped файл, или какая-то shared память, или считанный в буфер при помощи ReadFile файл), и чтобы что-то из него получить в фоксовый код при помощи sys(2600) потребуется: выделить в "куче" место под фоксовую строку, скопировать в неё содержимое из нашего блока памяти. И не важно хотим мы взять всего 1 байтик-символ или целиком всю большую строку - в любом случае путь идёт через фоксовый менеджер памяти, выделение блока под строку и копирование. Невозможно "напрямую" прочитать содержимое байтика таким образом.

запись:
SYS(2600, nAddress, nLen, cSrc)

cSrc - тоже фоксовая строка. Т.е. чтобы что-то записать в память из фоксового контекста, нам всё равно придётся создать фоксовую строку cSrc, передать её в sys(2600), где фокс уже произведёт копирование из "своей" строки в просто блок памяти по указанному адресу.

Суть всего этого в том, что мы в любом случае будем получать потери на вот этом "ненужном" копировании байтиков туда-сюда, плюс операции выделения и "форматирования" памяти из фоксовой кучи под эту самую строку. Невозможно напрямую, за 1 машинную операцию взять и прочитать байтик, или записать, или проверить что в нём установлен такой-то бит...

of63
Проблемой оказалась невозможность получить физический адрес фоксовой строки, фоксовыми средствами

Если бы такой способ и существовал (в собственно фоксе), он был бы по большому счёту бессмысленным, т.к. фоксовые строки находятся в "управляемой куче" и потому адрес строки вполне может измениться - фокс производит переупорядочение, дефрагментацию этой самой "кучи", и некоторые из строк при этом перемещаются.
В LCK (наборе АПИ функций для написания сишного кода взаимодействующего с фоксовыми структурами данных) есть специальные функции _HLock/_HUnLock которые позволяют "зафиксировать" некоторый фоксовый элемент данных (например строку) в памяти - указав фоксу не перемещать её никуда (анлок соответственно "освобождает" ранее зафиксированный элемент данных). После такой фиксации уже можно при помощи другой функции _HandToPtr транслировать хендл элемента данных (в том числе строки) в непосредственно адрес памяти где эта строка расположена.
Да, теоретически можно написать fll которая позволит фоксовому коду выполнять такие операции - но так делать не следует, лучше всю "логику" оставить в си-коде, просто следуя рекомендованному шаблону взаимодействия: "заблокировал" - получил из указателя адрес - поработал с этими данными в памяти - "разблокировал". всё это в рамках одной "внешней функции". Так чтобы блокировка/разблокировка осталась внутри одного логически связанного блока сишного кода.

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

Вот место, которое устанавливает бит в байте. Да куча фоксовых операторов кроме собственно SYS(2600), но позволило приблизиться к унарной операции "установить бит", и сильно ускорило процедуру, уж не знаю почему

"Переменная" и её содержимое это несколько разные вещи. Строки и объекты не хранятся внутри структуры памяти которую можно назвать "переменной" (скорее всего это та же самая структура которая описана в хелпе по фокс-апи как Value structure). И то что сама переменная при любых операциях присвоения остаётся той же самой (под неё не нужно снова выделять память - просто внутри уже существующей структуры поменяются какие-то поля), не гарантирует того что хранящаяся ВНЕ этой структуры сущность (объект или содержимое строки) не потребует перераспределения памяти.
Простые тесты показывают что между присвоением строковой переменной разных односимвольных значений и попеременно односимвольного и 10-символьного значения есть заметная разница в скорости. Очевидно что во втором случае фокс выделяет под более длинную строку отдельный блок памяти, что требует дополнительного времени. потом при присовении "короткой" строки он освобождает бОльший блок и выделяет новый - меньший.
"Двигать" что-либо в своей управляемой куче фокс будет лишь в случае нужды перераспределить память. "просто так" он не станет этим заниматься (зачем выполнять бессмысленную работу).

В любом случае приведенная тобой последовательность "взять байт по адресу X, установить бит N, записать байт обратно" при реализации на фоксе выливается в несколько сотен, если не тысяч машинных инструкций. Тогда как на ASM это будет всего одна единственная команда BTS (логику вычисления "адреса" и "номера бита" тут не учитываем - она нужна и в одном и во втором случае) - при том она заодно и начальное значение этого бита во флажок поместит, т.е. прочитает данные
Даже на си без ASM это можно написать сильно экономнее - что и следовало бы сделать если задача действительно критически важная по времени. Т.е. оформить ВСЮ функцию работы с этой битовой картой в fll на си, а из фокса уж дёргать.
Впрочем, я не исключаю и того, что собственно основную решаемую задачу (что там, поиск по списку "неправильных" номеров) можно было решить другим способом - не через битовую карту, а к примеру через B-tree. Естественно в этом случае вместо одной "логической" операции проверки одного бита по заданному адресу потребуется целая последовательность прохода по ветвям дерева - но этот вариант может оказаться сильно выгоднее по необходимой для работы памяти.

Игорь, блин, ты порешай практическую задачу, вт в моем примере большая паспортов. Теории сухи (как говорит Симпле)
и не уговаривай меня это прогу переделать (час-два - хсн, кто похваолится меньшими временами - покажите)
и не хочу ассемблер (ни один язык этого щастья в фоксеоставил, кроме Леонида)
и епусь я с государством, Игрь, а это просто затык непонятный, но обходимый
и, как сам чувствуешь себя в жизни? Важно, или не важно? )

> поиск по списку "неправильных" номеров
Поиск паспорта по битовой карте, это не девченкина задача, а есть подпрограмма. Девченку могу научить... )



Исправлено 1 раз(а). Последнее : of63, 06.01.20 22:03

И еще, ИК, не простые долбо..бы писали фокс, чтобы так взять, и на каждую переменную (или возврат из функции?!) выделять память. Так не пишут суперязыки.

Ой. В рамках ОС. Да все ОС одинваковы примерно... \



Исправлено 1 раз(а). Последнее : of63, 06.01.20 22:10