相关疑难解决方法(0)

我看到有一个eslint规则,no-return-await禁止return await.

在规则的描述中,它表示return await添加"extra time before the overarching Promise resolves or rejects".

但是,当我查看MDN async函数文档时,"简单示例"显示了一个示例,其中return await不包含任何可能导致性能问题的描述.

是return await一个实际的性能问题,因为eslint文档建议？

如果是这样,怎么样？

我在我的代码中的几个地方使用async/ await.

例如,如果我有这个功能:

async function func(x) {
    ...
    return y;
}

然后我总是这样称呼它:

async function func2(x) {
    let y = await func(x);
    ...
}

我注意到在某些情况下,我可以省略await并且程序仍然可以正常运行,因此我无法弄清楚何时必须使用await以及何时可以放弃它.

我已经得出结论,await直接在return语句中删除它是"合法的" .

例如:

async function func2(x) {
    ...
    return func(x); // instead of return await func(x);
}

这个结论是否正确,否则,我在这里错过了什么？

编辑:

一个小的(但很重要的)概念,在我刚刚遇到并实现的任何答案中都没有提到过:

它不是"合法"地掉落await一个内return声明,如果被调用函数可能会抛出异常,因此这种说法是内部执行try块.

例如,删除await下面的代码是"危险的":

async function func1() {
    try {
        return await func2();
    }
    catch (error) {
        return something_else;
    }
} …

-期望的行为
-实际行为
-我尝试过的内容
-再现步骤
-研究

期望的行为

从多个api请求接收的多个可读流通过管道传输到单个可写流。

api响应来自ibm-watson的textToSpeech.synthesize（）方法。

需要多个请求的原因是因为该服务5KB对文本输入有限制。

因此18KB，例如一个字符串，需要四个请求才能完成。

实际行为

可写流文件不完整且出现乱码。

该应用程序似乎“挂起”。

当我尝试.mp3在音频播放器中打开不完整的文件时，它说文件已损坏。

打开和关闭文件的过程似乎会增加文件的大小-就像打开文件一样，它会促使更多数据流入其中。

对于较大的输入（例如，四个4000字节或更少的字符串），不良行为更加明显。

我尝试过的

我尝试了几种方法，使用npm包Combined-stream，Combined-stream2，multistream和archiver 将可读流传递给单个可写流或多个可写流，它们都会导致文件不完整。我最后一次尝试不使用任何软件包，并在Steps To Reproduce下面的部分中显示。

因此，我在质疑应用程序逻辑的每个部分：

01. Watson文本对语音API请求的响应类型是什么？

语音文档的文本，表示api响应类型为：

Response type: NodeJS.ReadableStream|FileObject|Buffer

我很困惑，响应类型是三种可能的事情之一。

在所有尝试中，我一直假设它是一个readable stream。

02. 我可以在一个地图函数中发出多个api请求吗？

03. 我可以在中包装每个请求promise()并解决response吗？

04.是否 可以将结果数组分配给promises变量？

05. 我可以声明var audio_files = await Promise.all(promises)吗？

06. 声明之后，所有答复都“完成”了吗？

07. 如何正确地将每个响应传递给可写流？

08. 如何检测所有管道何时完成，以便可以将文件发送回客户端？ …

我正在寻找一些 eslint 选项，或者其他一些方法来在调用类内的异步方法之前检测是否缺少“await”关键字。考虑以下代码：

const externalService = require('./external.service');

class TestClass {

constructor() { }

async method1() {
    if (!await externalService.someMethod()) {
        await this.method2();
    }
}

async method2() {
    await externalService.someOtherMethod();
}

module.exports = TestClass;

如果我将 method1 转换为：

async method1() {
    if (!await externalService.someMethod()) {
        this.method2();
    }
}

我尝试对“.eslintrc”文件执行以下操作：

"require-await": 1,
"no-return-await": 1,

但没有运气。有人知道这是否可能吗？多谢！

我需要澄清一些关于Node.js,Promises,CPU和性能的内容.

为了设置上下文,我将讨论多次执行的异步处理(数据库查询)(在循环中),然后在所有异步之后执行其他操作.处理完成.

让我们从代码示例开始:

async function databaseQuery() {
    return await connection.query('SELECT * FROM example;');
}

我想执行n次异步调用(databaseQuery函数),当这些n次执行结束时,执行其他操作.

让我们使用并行Promises来实现这个目标:

const array = [...]; // Assuming this array is full of whatever

const promises = array.map(async (item) => {
    return await databaseQuery();
});

await Promise.all(promise);

// Ok now I'm sure all async calls are done

我尝试在两个环境中实现此代码:

• 本地计算机,Windows 10 x64,Intel i7 6c/12t,16g RAM
• 远程服务器(虚拟化服务器@ OVH),Ubuntu 16.04,1vCore,6g RAM

显然,本地机器上的性能远远优于远程机器(<1秒vs.> 1分钟).

但我需要一些关于为什么的精确度？.我知道物理材料在本地机器上更好.

此外,由于Node.js在单个核心上的单个线程上运行,为什么Windows资源使用10个线程和6个处理器监视Node.js进程？

代码中没有实现"多处理"代码(cluster …

我正在使用节点 v8.10.0

• Node.js 尾部调用优化：可能吗？

上述问题解释了 Node.js 如何不再支持 TCO。我最近遇到了这样的函数问题：

async function processBatch(nthBatch) {
    // do a bunch of async work and build up variables
    await processBatch(nthBatch + 1);
}

该代码存在内存泄漏，通过将其更改为：

async function processBatch(nthBatch) {
    // do a bunch of async work and build up variables
    return processBatch(nthBatch + 1);
}

我很惊讶这实际上有效，因为在上面描述的问题中，它清楚地解释了 Node 8.x 不支持 TCO。那么，是否有什么特殊的事情可以实现 TCO？或者是因为它在引擎盖下使用了生成器，并且返回将生成器标记为已完成，因此可以丢弃堆栈？

有什么区别吗

const foo = async () => {
  // some other code that uses await
  return await bar()
}

和

const foo = async () => {
  // some other code that uses await
  return bar()
}

bar返回 Promise 的函数在哪里。

这是await多余的还是有什么区别？