Страницы: Пред. 1 2 3 4 5 6 7
RSS
Возможности разработки взаимодействия с БД (выбор инструментов), Javascript ИЛИ VBScript
 
Конечно, это часть аналитики (в Excel c формированием PDF-презентации), другая в ERP, Cognos, WEB-интерфейс интернет магазина и т.д. Есть конечно и свои проблемы, но по теме...
Закрыть доступ ко всему, админам всегда проще, чем нормально отладить систему, с нормальной функциональностью, не в укор Медведю (с папироской). Со своей колокольни.
А может всех всё устраивает, кроме, тех нескольких аналитиков-негров и все готовы считать в WORD - такое тоже видел.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
egonomist написал: R легко конектится к бд, можно делать параллельные вычисления, куча пакетов для json.
Цитата
egonomist написал: knime - парсинг json
Parsing .txt files in Json format with a java in knime (правда без ответа)
оно?
так вы на Linux'e сидите?
или эта java и на Windows хорошо себя рекомендует?
или у вас knime на Windows?
Изменено: JeyCi - 04.12.2019 19:28:55
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал:  Базы  ... с доп обработками и join-ми
вообще, справедливо - цены отдельно, штуки отдельно... (отдельные сущности)
но когда цены плавают каждый день, то сразу к ним и штуки join'ю, ещё на этапе загрузки в бд... чтобы потом не join'ить на выгрузке... хотя эти цены и не особо нужны [скорее выступают просто параметром на каждый соотв. день, используются иногда в доп вычислениях], т.к. капитализация считается из др. цен :oops: ... вобщем всё зависит от бизнес-модели... но за справедливое замечание спасибо
(к слову о значимости схемы БД - для скорости обращения к ней)
Изменено: JeyCi - 16.11.2019 17:57:24
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Базы данных в Python
- всё-таки имеются модули в Python для работы с БД через ADO - так и называются adodbapi, pyodbc,
p.s. (доп. выводы к уже рассмотренному по Python):
1) асинхр. запросы к вэб - модуль aiohttp - вывод внесла сюда
2) модуль aio (aio_read) для асинхр чтения - работает только в POSIX OS (aka UNIX, can in Linux)
3) модуль asyncio (NB async/await syntax added in Python 3.5 ) оттестировала.......... на моих данных ОПТИМАЛЬНО пока получилась подгрузка 400 линков в 3 асинхр Tasks за 32сек, при добавлении 4-й Task выполняется 17 сек, НО загружается ~285 линков, остальные Access Denied -- стабильность результата не проверялась! завтра можно посмотреть ещё  :) Async IO in Python: A Complete Walkthrough
4) multiprocessing даёт инструменты реализовать конкурентное программирование (с вытекающими отсюда possible bugs - e.g. Race Condition - чтобы его избежать - надо использовать Inter-Process-Communication [доп накладные расходы])... - НО главное: Почему Python multiprocessing нестабилен - в Windows!... поэтому у меня не все примеры из сети работают - отсюда 2-й пример- вроде ок для начала.... НО NB Python multiprocessing is different under Linux and Windows
(5) хотя удобство функции Map() (в multiprocessing) стоит отметить (для сокращения количества кода)
===
подсказка с habr
Изменено: JeyCi - 25.11.2019 08:41:30
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Таким образом, мои впечатления от Python - c учётом того, что
Цитата
Python очень удобный, но очень медленный
- полагаю, по этой причине и был введён модуль asyncio - чтобы ускорить работу сервера при поступлении на него многих запросов от юзеров... сам по себе, полагаю, Python для PHP сродни VBScript (в IE новых версий не поддерживается) и JavaScript для html (не путать с JScript - последний проще и к нему есть доступ из ref. ScriptControl v.1.0 - в VBA)...
НО появился asyncio с его event loop'ом только в v.3.5 (~2015г)... ДО НЕГО был модуль concurrent.futures...
так что возможности Parallelism, Concurrency, Threading (ru, en) - хоть и существовали и ранее, но требовали (как всегда) доп. накладных расходов для Synchronization & Inter-Process-Communication (часто во избежание Race Condition)... и эта линейка была дополнена asyncio модулем (и его async/await syntax) - достаточно удобным...
что самое интересное - имеются рекомендации и иного способа ускорить Python - а именно, скрестить его с C/C++... (ссылки есть в линке на toster.ru предыдущего поста)
но, как мы уже убедились из работы от bedvit - VBA тоже запросто скрещивается с C/C++... причём в C/C++ asyncio API появляется с C++v.11 (2011г) - хотя и сам по себе код, работающий с памятью, - может работать быстрее, чем интерпретируемый код... - поэтому надобность реализовывать асинхр. функции в C/C++ под вопросом (IO в принципе достаточно быстр - проблемы со скоростью м. иметься только при необходимость обработки 1000 файлов или запросов, или около того... - ввиду блокирующей природы IO...
Касательно выбора способов ускориться:
- наличие нужных библиотек (пакетов) в IDE для кодирования тех или иных задач - это единственный важный фактор в выборе языка и IDE для кодирования на нём (с прилагающимися в ней библами)... либо писать свои пакеты (библы) в любой IDE на любом языке, поддерживаемом ей...
конечно же, при выборе инструментов, например, для создания асинхр. кода на Python, также не стоит забывать и о high-level APIs & low-level APIs возможностях (а следовательно и структуре кода)... первые - для написания программ, вторые - для написания библиотек или сред на основе asyncio... не забывая, что
Цитата
Если вы не пишете фреймворк или библиотеку, вам никогда не нужно трогать API низкого уровня
===
удобство работы с JSON, как в Python, так и в С/С++ (можно было библы найти всегда) - существовали уже давно... в PowerQuery появились с его появлением (~2010г)
===
а вот для асинхронности выполнения запросов к БД - в Python (после появления asincio) - были разработаны и aiopg (для PostgreSQL) и aiomysql (для MySQL) и aioodbc, хотя неасинхронные прототипы этих модулей существовали  и ранее... и здесь отмечены подробности возможностей (иногда невозможностей) для реализации асинхр. выполнения запросов (в частности, природа aioodbc ;) - который was based on pyodbc)
Цитата
Note that most database libraries are often implemented in C and the communication with the database happens at the C level, outside the reach of Python and often using threads underneath, so an asyncio driver would not be able to pass back control to an event loop.
имеется и simple asynchronous projects with the Sanic framework - заявляют, что поддерживают и SQLite (хотя SQLite - уже в архиве для Microsoft, и на смену ему пришли и MS SQL Server Local DB & Express версия, допускающая до 10-ти подключений)... кстати можно, возможно, попробовать распараллелить запросы к Express из-за proxy, раз он может принять несколько юзеров, - но это только в сетевой версии, полагаю (не на дом пк)...
Цитата
By providing a proxy server to SQL Server, it is able to support asynchronous calls
...
вобщем, в принципе - возможности для взаимодействия с БД - в Python были всегда, начиная с adodbapi Python 2.4, 2.5... к MS SQL Server 2005 и MS Access - только ADO...
но ADO, как мы знаем, прекрасно работает и из VBA...
===
поэтому, говоря о Python - сложно говорить об ускорении (только если с 2015-го года немного ускорить самого питона, но не свой проект на vba)...
а вот возможности C/C++, работая с памятью, - действительно, многогранны и смогли ускориться ещё до питона :) [за счёт того, что у С-языка низкий уровень вхождения] (хоть и не самый низкий, как у ассемблера)... С++ даёт удобные wrappers, да и сами references for containers, а где надо опуститься на уровень ниже для скорости - задействовать С API способы реализации быстрых алгоритмов
Изменено: JeyCi - 23.11.2019 14:59:00
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
... а всё зависит от того, КАКИЕ УРОВНИ АБСТРАКЦИИ разработчик может создавать сам, а какими уровнями абстракции, уже реализованными в библиотеках языка, - он зажат в определённые рамки самой библиотеки (более высоко-уровневого языка), которые не всегда удобны для его конкретного проекта... и пользуясь этими имеющимися библиотеками "as is" - он не имеет возможности обустроить какие-либо классы/объекты/сущности более удобным для себя способом (для себя - т.е. для своей Архитектуры конкретно под задачу), т.к. этим "шлюзом", в виде библиотеки, ему закрыт доступ к более низкоуровневым способам реализации именно его потребностей при работе с данным классом... ВЫВОД: либо самому писать на низкоуровневом языке с самого начала выстраивая свою архитектуру, либо всякими правдами-не-правдами (переопределение класса, делегаты, наследование, абстрактные классы, public/private определения, да и просто банальные if'ы и select_case'ы) пытаться выкрутиться в рамках уже имеющихся в библиотеке уровнях абстракции, задающих строго лимитированный объём методов и свойств в строго определённых зависимостях др. от др... строго определённых - определённых библиотекой... получается наворот лабиринтовых строк в коде - вместо прямолинейной логики машинного понимания...
... значимость реализации тех или иных уровней абстракции на том или ином уровне языка навеяна этой статьёй - в части
Цитата
чтобы мы смогли получить четкое разделение логики получения бинарных данных из канала ввода/вывода и логики интерпретации этих самых данных. Такая абстракция очень важна, поскольку в большинстве библиотек ввода/вывода в Python присутствует достаточно сильная связность между реализацией канала ввода/вывода и обработкой данных, которые пришли из этого канала. Это основная проблема пакета http стандартной библиотеки Python, поскольку в нем отсутствует отдельный HTTP-анализатор, а объект соединения выполняет всю работу по вводу/выводу и обработке. И если вы надеялись, что requests получит поддержку асинхронного программирования, вашим надеждам не суждено сбыться, поскольку синхронный ввод/вывод является неотделимой частью общей архитектуры
:) так что простым asincio и его async/await даже просто много файлов будет НЕ считать асинхронно, поскольку, вполне вероятно, что такая же история, как и с запросами, - неразрывная связь "между реализацией канала ввода/вывода и обработкой данных, которые пришли из этого канала" - и всё это проделки стандартной библиотеки, которую, чтобы обойти, - придётся опускаться на более низкий уровень вхождения... а по-другому никак... имхо (поэтому все асинхр библиотеки Python - aiohttp, aiofiles, aiostream, aio - создавались сами по себе, и поэтому простое заворачивание в async обычных функций - не спасает ситуацию без самих асинхр. библиотек для тех или иных целей -- написанных, полагаю тоже далеко не на Python, а всё может быть - что на более низкоуровневом языке)...
... так что вариант - "быстро читать файлы" на Python (в смысле асинхронно) тоже становился возможным только после 2015г (после появления async и всех её модификаций)...
пример aiofiles

а ранее - ускорение чтения файлов на Python'e -- тоже можно было достичь банально скрещиванием питона с С  :idea:
P.S.
и тем не менее, как всегда:
(особенно справедливо для парсинга, который иногда приходится переписывать под новый вид подачи данных)
Цитата
избежать дублирования кода поможет хорошо продуманная АРХИТЕКТУРА!
- с учётом выбранных библиотек
===
в двух словах:
!! языком язык не ускорить... только новыми уровнями абстракции с более низко-уровневого языка (т.е. др. языка)... заданными в новой библиотеке/пакете/надстройке
Изменено: JeyCi - 20.02.2020 10:06:24
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Касательно Архитектуры всё-таки оставлю линк:
Создание архитектуры программыкомпозиция vs наследования, или "Разделяй и властвуй"), - как всегда, в комментах (этого линка) повод задуматься...
и ещё раз задуматься при рассмотрении концепций разработки игр -
Цитата
В будущем, если игра окажется успешной, мы будем развивать ее дальше.
- становится понятна риторичность всех вопросов касательно архитектуры и ООП... поскольку не всегда "будем", и не всегда "мы"... отсюда возникает мудрость последнего коммента первого линка:
Цитата
Архитектура всегда есть, вы всегда можете выделить из системы компоненты, описать их взаимодействие и т.д. То что она формироваться должна не по принципу «надо все продумать» а по принципу «не знаешь какое решение тут лучше, сделай проще и так, что бы было удобно переделать», это уже другое.
... посему паттерны проектирования - на любителя...
... а если придётся рефакторить - то там же, и там же...
===
лучше увидеть Финиш ДО начала кодирования  ;)
Изменено: JeyCi - 04.12.2019 19:30:18
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
касательно .NET:
на www.connectionstrings.com - бросается в глаза:
Цитата
Asynchronous processing - A connection to SQL Server that allows for the issuing of async requests through ADO.NET objects.
Код
Server=myServerAddress;Database=myDataBase;Integrated Security=True;
Asynchronous Processing=True;
так что с асинхронностью запросов к SQL Server - в NET всё может обстоять очень даже на уровне (и не надо писать библы самим)... ещё не тестировала... но если ускорит выгрузку ~10 запросов - то вещь неплохая - хотя согласно спойлеру из #184 - не думаю, что при выгрузке с сервера может иметься проблема io_very_slow - если выборки до 1000 records... и скорее всего на 10 query'ях большого прироста не получить...
а, если с Access, то - т.к. выгрузки по сути небольшие, то на медлительном Access (даже если пробовать набросать С# надстройку) - даже если и сработает асинхронная выгрузка query'ей, то по скорости не удастся превзойти возможностей медленного Access... имхо
p.s. здесь
Цитата
Beginning in the .NET Framework 4.5, these legacy methods no longer require Asynchronous Processing=true in the connection string.
Изменено: JeyCi - 04.12.2019 19:22:16
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: с асинхронностью запросов к SQL Server - в NET всё может обстоять очень даже
как обычно...
Цитата
if your backend is a single SQL server database, and every request hits that database, then there usually isn't a benefit from making your web service asynchronous.
только для web-версий
Цитата
, if your backend is a SQL server cluster or Azure SQL, then you can get a scalability benefit by using an asynchronous web service implementation.
p.s.
для иных целей, нежели запросы к бд - в JavaScript async/await такой же, как для python, только со своим синтаксисом
Изменено: JeyCi - 04.12.2019 19:24:31
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
C# How to Async download multiple files using webclient simultaneously?
C# также реализовал async/await - примерно, как python...
Цитата
When you are using keywords async/await then you are running that specific code on another thread. That means that your code will not block Main thread.
... и уже из кода можно грузить в БД, распарсенные json'ы...
на С# и надстройку можно сделать для VBA, насколько понимаю...
Изменено: JeyCi - 06.12.2019 19:09:19
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: C# также реализовал async/await - примерно, как python...
добавлю лишь, коммент по линку
Цитата
If you look in the Remarks section for the ".NET Framework (current version)" of HttpClient you will see it states CancelPendingRequests, DeleteAsync, GetAsync, GetByteArrayAsync, GetStreamAsync, GetStringAsync, PostAsync, PutAsync, and SendAsync are all thread safe.
что непосредственно наталкивает на мысль о том, что не используя эти методы (а другие взамен них) - обязывает вместо имеющегося у первых соотв. wrapper'а создавать своё его подобие или иным способом позаботиться о thread safety множественных запросов... иначе так и будем стоять в очереди на сокет... подумалось мне  8)...
или чего хуже - испытаем на себе Race Condition или memory leaks...
p.s.
хотя в любом случае ограничения на доступ от одного IP придётся учитывать, но 2-3 Task'a можно зарядить на сайт (в зависимости от сайта)...
p.p.s.
это, полагаю, дополнение к объяснению по python о целесообразности использования async/await именно совместно с асинхр. методами, а не какими другими... только свои механизмы, возможно, в др языке... но суть как обычно - всё идёт от библиотек...   :excl:
Изменено: JeyCi - 11.12.2019 12:34:54
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
а парсить json, имея predetermined structure его - можно и Классом по полям с использованием regex... имхо... даже не напрягаясь поисками удобной библиотеки... хотя Newtonsoft.Json совместно с Newtonsoft.Json.Linq в C# дают удобное раделение JToken по JObject и JArray и обращение к ним... да и JsonReader.Async.cs в исходниках - прибавляет оптимизма...
===
(если взаимодействовать с сервером через web или сервером Azure, вероятно, - передавая json'ы туда-сюда... утилита для разбора... но в VS её подобие тоже есть)
Изменено: JeyCi - 18.12.2019 16:18:48
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: дополнение к объяснению по python о целесообразности использования async/await именно совместно с асинхр. методами, а не какими другими...
добавила ремарку к коду #158, который набросала ещё тогда
Цитата
пример aiofiles -- PROBLEM: Race Condition !!
- т.е. асинхр библа python'a всё равно не защитила от Race Condition !
то ли дело в библе, то ли в коде -- просто оставляю пост для инфо... - не все json-структуры сохраняются в файлы...
библиотеки С# ещё не пробовала
Изменено: JeyCi - 20.02.2020 10:05:17
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: Касательно Архитектуры
всё не так сложно - хорошие ответы на форуме кибера - даже без книжек  :)
Как придумать классы по описанию проекта
ООП, понимание абстрактных классов/методов и т.п
Какую архитектуру программы лучше выбрать?
... и иные из той же ветки и там же...
Изменено: JeyCi - 16.02.2020 11:31:30
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
доп к #193 -
Итак, чтобы добраться до истины -
то, что кто-то где-то называл асинхронностью может оказаться многопоточностью по сути
, надо вспомнить пост от bedvit
Цитата
Race Condition относится к Многопоточности
и мой пост
Цитата
в более ранних статьях и разработках на Python - какие-то проблемы с лексикой - когда смешивают в кучу асинхронность и многопоточность
Терминология - Многопоточное vs асинхронное программирование
вводя условное слово Task  в примерах по асинхронности на Python - разработчики Python в скором времени получают иную интерпретацию и смысл слова Task от Microsoft в их TASK PARALLEL LIBRARY (TPL) - NET 4.0
Цитата
нет возможности использовать оптимальное количество потоков в зависимости от имеющегося оборудования, если явно об этом не позаботиться.
Иными словами, вместо решения прикладной задачи разработчик вынужден кучу сил тратить на борьбу с недружественным окружением.
Решение этих проблем в TPL начинается с того, что вместо привычных потоков вводится другая базовая абстракция – Task (задача).
--- но тем не менее это параллелизм...  :excl: (по крайней мере в контексте TPL от Microsoft - создаётся ощущение из той статьи - ссылка ниже)... хотя Асинхронное программирование в C# 5  :( вот так путаница и возникает - как следствие: пока не проверишь, не знаешь, с чем имеешь дело...
***
по Параллелизму - описание цитаты и др. нюансов в статье на RSDN.org - Эпоха параллельности ... там же про LINQ и про PLINQ
Цитата
Существует довольно большой класс задач работы с данными, который отлично распараллеливается и естественным образом разбивается на оптимально гранулированные подзадачи, о которых говорилось ранее – это различного рода объединения, фильтрация, группировка и прочие операции с наборами данных. В .Net 3.5 для такого рода задач была представлена библиотека декларативных запросов – LINQ, и это отличный кандидат на автоматическое распараллеливание. Собственно, о привлекательности декларативности в этом аспекте уже говорилось ранее. Когда код декларативен, очень многие решения можно отдать на откуп компилятору/оптимизатору/библиотеке, которые лучше знают о конкретном окружении, числе ядер и прочих особенностях... PLINQ ровно это и демонстрирует
[хотя для считывания JSON и LINQ to Json (цель - запросы) не нужен в c#, достаточно просто библы Newtonsoft, aka JSON.NET]... но для Join'ов разных json'ов (если надо) - только LINQ
P.S.
в той статье на RSDN и проблема Out of Memory объяснена
Цитата
если бы каждая итерация была потяжелее (или алгоритм вообще реализовывался через рекурсию), то все эти потоки висели бы в памяти, что в перспективе привело бы к OutOfMemory
о чём впрочем bedvit и писал
Цитата
потоки будут стоять в очереди на ядро
---
вобщем всё дело терминологии языка - это дело абстракций и их сути, которые насоздавали в разные времена в разных языках без оглядки на конкурентов (очередное доказательство тго, что сотрудничество всегда лучше конкуренции)... отсюда и возникает путаница и затраты времени на поиск объяснений "что это значит" при попытке выбрать более соотв. язык, чем VBA для тех или иных задач - (например для ускорения с помощью добавления асинхронности)
хотя возможно и библиотеки NET с их асинхр. возможностями можно как-то подключить в VBA... но пока тупо через Tools/Reference не вижу возможностей... только создание надстроек на C#... хотя тоже вопрос спорный ввиду IL природы c#'а - т.к. Comparing LINQ with Stored Procedure - Stored procedures Сервера по скорости более выгодны, чем LINQ  :excl:  (тестировать не хочу, поверю статье по линку)
Изменено: JeyCi - 20.02.2020 10:20:00
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:  :(  вот так путаница и возникает - как следствие: пока не проверишь, не знаешь, с чем имеешь дело...
но в принципе Microsoft расставляет всё по своим местам в своей документации по C# - Асинхронное программирование
Цитата
Перед написанием любого кода нужно ответить на два вопроса.
1.Будет ли код "ожидать" чего-либо, например данных из базы данных?
Если ответ утвердительный, то ваша задача ограничена производительностью ввода-вывода. (IO-bound)
2.Будет ли код выполнять очень сложные вычисления?
Если ответ утвердительный, то задача ограничена ресурсами процессора. (CPU-bound)
!!!
Если ваша задача ограничена производительностью ввода-вывода (IO-bound), используйте async и await без Task.Run. Библиотеку параллельных задач использовать не следует. Причина этого указана в статье Подробный обзор асинхронного программирования.
Подробный обзор асинхронного программирования
Цитата
Код async, связанный с использованием ЦП, немного отличается от кода async, связанного с операциями ввода-вывода. Поскольку работа выполняется на ЦП, невозможно избежать выделения потока для вычислений. Использование async и await предоставляет чистый способ взаимодействия с фоновым потоком и позволяет объекту, вызвавшему асинхронный метод, по-прежнему реагировать на новые запросы. Обратите внимание, что это не обеспечивает защиту общих данных. Если вы используете общие данные, все равно потребуется применять соответствующую стратегию синхронизации.
Цитата
CalculateResult() выполняется в потоке, в котором он вызывался. Когда он вызывает Task.Run, он помещает дорогостоящую операцию, связанную с ЦП, DoExpensiveCalculation(), в очередь пула потоков и получает дескриптор Task<int>. DoExpensiveCalculation() в конечном счете выполняется параллельно в следующем доступном потоке
-- значит над #158, вероятно, надо ещё поколдовать - чтобы скачивать и скидывать данные каждые в свой файл... хоть в таком ТЗ вроде и нет задач для ЦП, но куда-то они (данные) утекают не доходя до файла??... какую-то защиту, вероятно, надо бы создать... ИЛИ (как в цитате)
Цитата
Если вы используете общие данные, все равно потребуется применять соответствующую стратегию синхронизации.
Изменено: JeyCi - 20.02.2020 15:28:40
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: -- значит над #158, вероятно, надо ещё поколдовать - чтобы скачивать и скидывать данные каждые в свой файл... хоть в таком ТЗ вроде и нет задач для ЦП, но куда-то они (данные) утекают не доходя до файла??...
SORRY  :oops:
был у меня такой код (доработанный из примера #158) - долго не использовала - вспомнила, откуда там появлялись пустые файлы - там проверка получаемой строки с url'a на ответ "Access Denied" (т.к. запросы в сеть на сторонний сайт, и не через ASP MVC, а просто кодом Python) ==> это была не проблема асинхронности, а вопрос защиты стороннего сайта.....
и не Race Condion это был  8)
p.s.
ну хоть в вопросы асинхронности заглянули ещё раз  :)
значит, асинхронность - это хорошо, но только когда обращаешься к своему серверу/сайту
Изменено: JeyCi - 20.02.2020 15:32:10
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
... и суровая правда жизни программистов  :evil:
(которую непрерывно отказываются понимать заказчики  8-0 ):
Цитата
совершенно очевидно, что для любого ТЗ можно легко придумать такую правку, из-за которой придется радикально переписывать программу.
P.S.
... А если правильна выбрана Архитектура??... и правильно выбраны инструменты для реализации... -- время покажет
Изменено: JeyCi - 08.03.2020 10:40:08
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
... А если правильно выбрана Архитектура??... и правильно выбраны инструменты для реализации...
продолжение на С++... (сугубо по собственным задачам проекта - Архитектура в первом приближении)...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Есть очень неплохая разработка под пользовательские БД (не промышленного масштаба).(бесплатно)
В качестве базы используется  Firebird. Очень много конечно не хватает, но вполне заслуживает внимания!
Тынц
Изменено: R Dmitry - 30.04.2020 11:11:59
Спасибо
 
Выбор языка - Py vs C++ vs Java (для Клиента)
Изменено: JeyCi - 14.04.2020 06:23:57
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
касательно подгрузки из i'net модуль aiohttp НЕ на всех сайтах ОК (хоть и ~5sec): НО при большом количестве запросов (~400) к сайту - Access Denied на многие линки (хоть и не все) ...
- проблема вскрыта - нужен лимит на количество одновременно подгружаемых линков... иначе вылазит Access Denied...
но природа py aiohttp в принципе понятна - вряд ли распараллеливание по fibers, скорее просто асинхронность через один сокет...
Изменено: JeyCi - 28.05.2021 10:02:24
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
вопросы ускорения за счёт асинхронности (и aiofiles) или многопоточности - рассмотрели здесь
Изменено: JeyCi - 28.05.2021 10:01:18
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал:
Можете сравнить с предыдущим, посмотреть отличия (с CComBSTR перешел на _bstr_t ).
:) на память - #118 и #143
Скрытый текст

ИТОГ ветки: Ускорили сортировку на стороне MS Access, подключив С++ библиотеку от bedvit (начиная с #184) и пример её использования в VBA (на примере MS Access) -  #205 ...
ничего более из рассмотренного так хорошо не помогло, как замена родного для Access - ORDER BY на реализацию сортировки в С++...
Переход на MS SQL Server Express рассматривать только при наличии размеров БД до 10Гб и свыше (выше Express версии)... желательно с соотв. наращиванием мощностей железа (aka серверный ПК *x64)
P.S.
... последняя полная версия библиотеки BedvitCOM
... и много др. полезностей от автора здесь
Изменено: JeyCi - 27.06.2021 16:04:33
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Страницы: Пред. 1 2 3 4 5 6 7
Наверх