eladmarg commented on issue #763: URL: https://github.com/apache/lucenenet/issues/763#issuecomment-1322497950
no one said that async operation isn't needed. IO (network / disk) is async operation by definition. so yes, this is totally agreed that the correct way to access IO is async all the way. no need to say that this will impact much higher throughput to the system / index. even that lucene is "highly optimized to use a local file system". a local FS on the cloud is not always what you think in terms of FS, not always fast. but even if its local, it's still in order of magnitude slower than cpu/L1 cache. so while a thread waiting for IO, it can be freed and do another work or serve other queries. so to summarize, it's not a question if async should be supported. it's clearly as the sun. our problem is the scope and how and when can it be done. I really don't see how you can do it without breaking all the components. even with partial classes, the async operations should seep from the ground basic operations (Lucene.Net.Store.DataOutput) all the way up to the public api. so in some way, i can truly understand this is disappointing because we aren't utilizing the modern technology and the tools we already have. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
