From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 23:42:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE7098F4; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5576354; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=WxOiZICDi4Fxs7ESElswXGhp9FVcedpVd63mEOdP19o=; b=ckXTJTtjCHRM0MH2isErEP8ve4IPTwXF5z2mIgMcj+jSkzXNlT92It9TQyknD9aegJ7zmlRb4BjA134xT5lfPpFeIJ2ldsMmlthl2swGSJ3+VjIb5JRJ03T9D6ygjC8DB68xBKtxl16in5gpspjqeJm2ugXsAmmNoDSJLTzjBQk=; Received: from [182.9.153.44] (port=13067 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.82) (envelope-from ) id 1XjzLl-004LHS-9y; Thu, 30 Oct 2014 17:41:53 -0600 Date: Fri, 31 Oct 2014 07:41:49 +0800 From: Erich Dollansky To: bycn82 Subject: Re: performance of the swtich/case statements Message-ID: <20141031074149.591c09de@X220.alogt.com> In-Reply-To: References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:42:01 -0000 Hi, On Thu, 30 Oct 2014 12:24:33 +0800 bycn82 wrote: > Hi, > According to my understanding in Java programming, the compiler will aren't we talking about C here? Erich > automatically store the values into a table and jump to the correct > one according to the value only when the condition values are in > running number, > > for example. > > swtich(a){ > case 1: code block 1 > case 2: code block 2 > case 3: code block 3 > case 4: code block 4 > default: code block 5 > } > > it will be handled by an array > 1-->code block 1 > 2-->code block 2 > 3-->code block 3 > 4-->code block 4 > others-->code block 5 > > so when the value N is greater than or lesser than 1, it will be > directly jump to the "code block 5" > otherwise, it will jump to N, because call the cases are nice in > running numbers, > > but when the cases are messy, it will by just like lots of if/else > > > On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > Hi, > > > > On Wed, 29 Oct 2014 22:39:34 +0800 > > "bycn82" wrote: > > > > > It is using the switch/case statement to make the code clear in > > > the > > > > > > I am not a C programmer, so I am not clear how the switch/case > > > will be optimized by the compiler in FreeBSD. But I used to write > > > a compiler by myself and I use a hash table to handle all the > > > conditions in the case statements because my compiler don't care > > > about performance!, But in C it is different, the case statement > > > can only accept "int" values, so I don't think it will use hash > > > or what , it should be directly use an array(), So whether it can > > > be optimized it depends on the conditions in the switch/case > > > statements, and I noticed that the cases statement in the 2 loops > > > are not arranging the opcode in running number, so does the > > > compiler smart enough to optimize it? > > > > > > > > I did not check recently. It was already a long, long time ago, that > > compilers checked the limits and used the values as an index into a > > table to jump to the code. I hope that this did not get changed. > > > > With other words, the order in the code does not matter. The only > > optimisation the compiler can do, is not to use a table if the > > statement consists of a low number of entries only. > > > > Erich > >