Конечно, это часть аналитики (в Excel c формированием PDF-презентации), другая в ERP, Cognos, WEB-интерфейс интернет магазина и т.д. Есть конечно и свои проблемы, но по теме... Закрыть доступ ко всему, админам всегда проще, чем нормально отладить систему, с нормальной функциональностью, не в укор Медведю (с папироской). Со своей колокольни. А может всех всё устраивает, кроме, тех нескольких аналитиков-негров и все готовы считать в WORD - такое тоже видел.
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
bedvit написал: Базы ... с доп обработками и join-ми
вообще, справедливо - цены отдельно, штуки отдельно... (отдельные сущности) но когда цены плавают каждый день, то сразу к ним и штуки join'ю, ещё на этапе загрузки в бд... чтобы потом не join'ить на выгрузке... хотя эти цены и не особо нужны [скорее выступают просто параметром на каждый соотв. день, используются иногда в доп вычислениях], т.к. капитализация считается из др. цен ... вобщем всё зависит от бизнес-модели... но за справедливое замечание спасибо (к слову о значимости схемы БД - для скорости обращения к ней)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Базы данных в 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
Цитата
следовать этому псевдо-коду if io_bound: if io_very_slow: print("Use Asyncio") else: print("Use Threads") else: print("Multi Processing") 'meaning CPU-bound - mostly calculations
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Таким образом, мои впечатления от 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 способы реализации быстрых алгоритмов
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
... а всё зависит от того, КАКИЕ УРОВНИ АБСТРАКЦИИ разработчик может создавать сам, а какими уровнями абстракции, уже реализованными в библиотеках языка, - он зажат в определённые рамки самой библиотеки (более высоко-уровневого языка), которые не всегда удобны для его конкретного проекта... и пользуясь этими имеющимися библиотеками "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
Код
import asyncio
import aiofiles
import time
import pathlib
async def task(name, work_queue):
cn=0
while not work_queue.empty():
f = await work_queue.get()
async with aiofiles.open( f, mode='r') as ff:
contents = await ff.read()
#print(contents)
#print("------------------------------------------")
cn=cn+1
print(cn)
async def main(files):
# Create the queue of 'work'
work_queue = asyncio.Queue()
# Put some 'work' in the queue
for f in files:
await work_queue.put(f)
await asyncio.gather(
asyncio.create_task(task("One", work_queue)),
asyncio.create_task(task("Two", work_queue)),
asyncio.create_task(task("Three", work_queue))
)
def files_all() -> list:
p = pathlib.WindowsPath("E:\\NEW")
files = [child for child in p.iterdir()]
print("Всего файлов: ", len(files))
return files
if __name__ == "__main__":
files=files_all()
start_time = time.time()
loop = asyncio.get_event_loop()
results = loop.run_until_complete(main(files))
elapsed_time = time.time() - start_time
print(time.strftime("%H:%M:%S", time.gmtime(elapsed_time)))
а ранее - ускорение чтения файлов на Python'e -- тоже можно было достичь банально скрещиванием питона с С P.S. и тем не менее, как всегда: (особенно справедливо для парсинга, который иногда приходится переписывать под новый вид подачи данных)
Цитата
избежать дублирования кода поможет хорошо продуманная АРХИТЕКТУРА!
- с учётом выбранных библиотек === в двух словах: !! языком язык не ускорить... только новыми уровнями абстракции с более низко-уровневого языка (т.е. др. языка)... заданными в новой библиотеке/пакете/надстройке
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Касательно Архитектуры всё-таки оставлю линк: Создание архитектуры программы (и композиция vs наследования, или "Разделяй и властвуй"), - как всегда, в комментах (этого линка) повод задуматься... и ещё раз задуматься при рассмотрении концепций разработки игр -
Цитата
В будущем, если игра окажется успешной, мы будем развивать ее дальше.
- становится понятна риторичность всех вопросов касательно архитектуры и ООП... поскольку не всегда "будем", и не всегда "мы"... отсюда возникает мудрость последнего коммента первого линка:
Цитата
Архитектура всегда есть, вы всегда можете выделить из системы компоненты, описать их взаимодействие и т.д. То что она формироваться должна не по принципу «надо все продумать» а по принципу «не знаешь какое решение тут лучше, сделай проще и так, что бы было удобно переделать», это уже другое.
... посему паттерны проектирования - на любителя... ... а если придётся рефакторить - то там же, и там же... === лучше увидеть Финиш ДО начала кодирования
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
так что с асинхронностью запросов к 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.
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
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, только со своим синтаксисом
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
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, насколько понимаю...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
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 множественных запросов... иначе так и будем стоять в очереди на сокет... подумалось мне ... или чего хуже - испытаем на себе Race Condition или memory leaks... p.s. хотя в любом случае ограничения на доступ от одного IP придётся учитывать, но 2-3 Task'a можно зарядить на сайт (в зависимости от сайта)... p.p.s. это, полагаю, дополнение к объяснению по python о целесообразности использования async/await именно совместно с асинхр. методами, а не какими другими... только свои механизмы, возможно, в др языке... но суть как обычно - всё идёт от библиотек...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
а парсить json, имея predetermined structure его - можно и Классом по полям с использованием regex... имхо... даже не напрягаясь поисками удобной библиотеки... хотя Newtonsoft.Json совместно с Newtonsoft.Json.Linq в C# дают удобное раделение JToken по JObject и JArray и обращение к ним... да и JsonReader.Async.cs в исходниках - прибавляет оптимизма... === (если взаимодействовать с сервером через web или сервером Azure, вероятно, - передавая json'ы туда-сюда... утилита для разбора... но в VS её подобие тоже есть)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
JeyCi написал: дополнение к объяснению по python о целесообразности использования async/await именно совместно с асинхр. методами, а не какими другими...
добавила ремарку к коду #158, который набросала ещё тогда
Цитата
пример aiofiles -- PROBLEM: Race Condition !!
- т.е. асинхр библа python'a всё равно не защитила от Race Condition ! то ли дело в библе, то ли в коде -- просто оставляю пост для инфо... - не все json-структуры сохраняются в файлы... библиотеки С# ещё не пробовала
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
доп к #193 - Итак, чтобы добраться до истины - то, что кто-то где-то называл асинхронностью может оказаться многопоточностью по сути , надо вспомнить пост от bedvit
Цитата
Race Condition относится к Многопоточности
и мой пост
Цитата
в более ранних статьях и разработках на Python - какие-то проблемы с лексикой - когда смешивают в кучу асинхронность и многопоточность
Терминология - Многопоточное vs асинхронное программирование вводя условное слово Task в примерах по асинхронности на Python - разработчики Python в скором времени получают иную интерпретацию и смысл слова Task от Microsoft в их TASK PARALLEL LIBRARY (TPL) - NET 4.0
Цитата
нет возможности использовать оптимальное количество потоков в зависимости от имеющегося оборудования, если явно об этом не позаботиться. Иными словами, вместо решения прикладной задачи разработчик вынужден кучу сил тратить на борьбу с недружественным окружением. Решение этих проблем в TPL начинается с того, что вместо привычных потоков вводится другая базовая абстракция – Task (задача).
--- но тем не менее это параллелизм... (по крайней мере в контексте 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 (тестировать не хочу, поверю статье по линку)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
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 написал: -- значит над #158, вероятно, надо ещё поколдовать - чтобы скачивать и скидывать данные каждые в свой файл... хоть в таком ТЗ вроде и нет задач для ЦП, но куда-то они (данные) утекают не доходя до файла??...
SORRY был у меня такой код (доработанный из примера #158) - долго не использовала - вспомнила, откуда там появлялись пустые файлы - там проверка получаемой строки с url'a на ответ "Access Denied" (т.к. запросы в сеть на сторонний сайт, и не через ASP MVC, а просто кодом Python) ==> это была не проблема асинхронности, а вопрос защиты стороннего сайта..... и не Race Condion это был p.s. ну хоть в вопросы асинхронности заглянули ещё раз значит, асинхронность - это хорошо, но только когда обращаешься к своему серверу/сайту
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
JeyCi написал: ... А если правильно выбрана Архитектура??... и правильно выбраны инструменты для реализации...
продолжение на С++... (сугубо по собственным задачам проекта - Архитектура в первом приближении)...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Есть очень неплохая разработка под пользовательские БД (не промышленного масштаба).(бесплатно) В качестве базы используется Firebird. Очень много конечно не хватает, но вполне заслуживает внимания! Тынц
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
JeyCi написал: касательно подгрузки из i'net модуль aiohttp НЕ на всех сайтах ОК (хоть и ~5sec): НО при большом количестве запросов (~400) к сайту - Access Denied на многие линки (хоть и не все) ...
- проблема вскрыта - нужен лимит на количество одновременно подгружаемых линков... иначе вылазит Access Denied... но природа py aiohttp в принципе понятна - вряд ли распараллеливание по fibers, скорее просто асинхронность через один сокет...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
I would typically use a CComBSTR instead of BSTR or _bstr_t. If you need reference counting then you have to fall back on _bstr_t. E.g: If you're also using ATL, you will probably only ever want CComBSTRs.
The CComBSTR class is a wrapper for BSTRs, which are length-prefixed strings. The length is stored as an integer at the memory location preceding the data in the string.
A BSTR is null-terminated after the last counted character but may also contain null characters embedded within the string. The string length is determined by the character count, not the first null character.
So, before making a choice do consider the following:
_bstr_t is a reference counted smart-pointer wrapper over BSTR whereas CComBSTR does not provide any reference counting. _bstr_t does not redefine the address-of operator and can thus be safely stored in a STL container. With CComBSTR you will need to use CAdapt. About the CAdapt object:
CAdapt is a simple template used to wrap classes that redefine the address-of operator (operator &) to return something other than the address of the object. Examples of such classes include ATL's CComBSTR, CComPtr, and CComQIPtr classes, and the compiler COM support class, _com_ptr_t. These classes all redefine the address-of operator to return the address of one of their data members (a BSTR in the case of CComBSTR, and an interface pointer in the case of the other classes).
ИТОГ ветки: Ускорили сортировку на стороне MS Access, подключив С++ библиотеку от bedvit (начиная с #184) и пример её использования в VBA (на примере MS Access) - #205 ... ничего более из рассмотренного так хорошо не помогло, как замена родного для Access - ORDER BY на реализацию сортировки в С++... Переход на MS SQL Server Express рассматривать только при наличии размеров БД до 10Гб и свыше (выше Express версии)... желательно с соотв. наращиванием мощностей железа (aka серверный ПК *x64) P.S. ... последняя полная версия библиотеки BedvitCOM ... и много др. полезностей от автора здесь
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)