From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 04:24:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9495E894; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66B35B6C; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id z10so4360936pdj.29 for ; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VMUDdhKaNCUrwzGu5Ba+FhLnYQX+/OK/XW4GIlKX1A=; b=lZO4UdIuYXuEpxfKLHVyqpHrdzAr6u1EyK7VzW8XX+phd5dgiOi8MO9Bx4Y55shXfK mQmwrR2VceOSbB/gydREc/bITfZ5/QHNSisPk/nvHxFb2LObyYJ6xniPYkFEq8iUvLOL npmTLwRLKvY45plVdK94E+eLv8w4KPU3AjERyvQxQZwyhAirictULkVeO+Y2h8vRo2h1 QcXXVgcYUQJVn0vR4erBMCBt4Bp34+kDPqmBV6uZHVq9mPjphhDWfQ8fYRXKNr/BznCw g0Dz7unEc93kyyhrSG+d0+oiH5SSUEanFEvowK6QGgg0gTyL7qSKeeeu7MgHvDJeBcdv iHlQ== MIME-Version: 1.0 X-Received: by 10.70.96.162 with SMTP id dt2mr14761368pdb.29.1414643074006; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) Received: by 10.70.42.228 with HTTP; Wed, 29 Oct 2014 21:24:33 -0700 (PDT) In-Reply-To: <20141030063053.12608314@X220.alogt.com> References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> Date: Thu, 30 Oct 2014 12:24:33 +0800 Message-ID: Subject: Re: performance of the swtich/case statements From: bycn82 To: Erich Dollansky , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: 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 04:24:34 -0000 Hi, According to my understanding in Java programming, the compiler will 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 >