All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	linux-kernel@vger.kernel.org, 2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH] perf-probe: no need to initialize the entire temporary buffers in synthesize_perf_probe_point()
Date: Mon, 27 Dec 2010 22:06:35 +0100	[thread overview]
Message-ID: <m3pqsnvsbo.fsf@gmail.com> (raw)
In-Reply-To: <20101224131441.GA3128@ghostprotocols.net> (Arnaldo Carvalho de Melo's message of "Fri, 24 Dec 2010 11:14:41 -0200")

Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:

> Em Fri, Dec 24, 2010 at 01:46:09PM +0900, Masami Hiramatsu escreveu:
>> (2010/12/24 0:27), Franck Bui-Huu wrote:
>> > This patches only put a single null byte at the beginning of each
>> > temporary buffers line[], offs[], file[] instead of filling their
>> > full contents with null bytes.
>
>> Hmm, sorry but NAK it.
>
>> IMHO, with modern chips, the original code has no problem from the
>> viewpoint of memory access (all are cached and no need to access just
>> one byte) nor a bottleneck.
>> I'd rather use '= ""' style initialization for local variables from the
>> viewpoint of readability.
>
> No strong feelings here, not really a fast path, just learned something
> new, I thought that that kind of initialization would be equivalent to
> what Franck proposed, but gcc really uses the most efficient way of
> zeroing the whole string (movq for things like that, and rep stos for
> bigger arrays, etc).
> 

gcc has no other choice than clearing the whole buffers here since it's
how C initialisation works.

Thanks
-- 
		Franck

  reply	other threads:[~2010-12-27 21:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-23 15:27 [PATCH] perf-probe: no need to initialize the entire temporary buffers in synthesize_perf_probe_point() Franck Bui-Huu
2010-12-24  4:46 ` Masami Hiramatsu
2010-12-24 13:14   ` Arnaldo Carvalho de Melo
2010-12-27 21:06     ` Franck Bui-Huu [this message]
2010-12-27 21:01   ` Franck Bui-Huu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3pqsnvsbo.fsf@gmail.com \
    --to=vagabon.xyz@gmail.com \
    --cc=2nddept-manager@sdl.hitachi.co.jp \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.