From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#41242: Port feature/native-comp to Windows Date: Sat, 23 May 2020 17:56:02 +0000 Message-ID: References: <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="48399"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 23 19:57:09 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jcYOT-000CVD-8k for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 May 2020 19:57:09 +0200 Original-Received: from localhost ([::1]:34534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcYOR-0008F5-Qu for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 May 2020 13:57:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcYOM-0008Eu-4w for bug-gnu-emacs@gnu.org; Sat, 23 May 2020 13:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52170) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcYOL-0004QI-S2 for bug-gnu-emacs@gnu.org; Sat, 23 May 2020 13:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jcYOL-00076S-Qi for bug-gnu-emacs@gnu.org; Sat, 23 May 2020 13:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 May 2020 17:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41242 X-GNU-PR-Package: emacs Original-Received: via spool by 41242-submit@debbugs.gnu.org id=B41242.159025656827234 (code B ref 41242); Sat, 23 May 2020 17:57:01 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:56:08 +0000 Original-Received: from localhost ([127.0.0.1]:35483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYNT-00075B-LS for submit@debbugs.gnu.org; Sat, 23 May 2020 13:56:07 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:51760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYNQ-00074y-0v for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:56:06 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NHu2TM005511 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 17:56:02 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NHu25k023496; Sat, 23 May 2020 17:56:02 GMT In-Reply-To: <83zh9yy2of.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 20:35:44 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180831 Archived-At: Eli Zaretskii writes: >> Coming back to the performance problem when loading: apart from reducing >> the number of files probed, we could try parallelizing openp() using a thread >> pool. What do you think? > > I'd start by reducing the number of probed files, and then I'd > benchmark the results and see if it's "good enough". Threads add > another dimension of complexity, so I'd only go there if we have a > very good reason. Agree, also I think before that would be necessary to prove that parallelizing in user space let the kernel scale up in performance in serving the syscalls. I'm not really sure about that and the observed bottle neck is apparently there. Andrea -- akrl@sdf.org