From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5a97e6705e234408 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-25 14:15:06 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Expected bytes per sloc (semicolons) performance Date: Tue, 25 Sep 2001 17:04:13 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9oqrgf$jc3$1@nh.pace.co.uk> References: NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1001451855 19843 136.170.200.133 (25 Sep 2001 21:04:15 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 25 Sep 2001 21:04:15 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:13365 Date: 2001-09-25T21:04:15+00:00 List-Id: Wellllll........ Maybe not *totally* useless. In the early phases of a project you need to get some half-way reasonable grasp on what you think you're going to need in the way of memory. So maybe you've got experience with a similar application and you can run some or all of its code through a known compiler and see what you get in terms of bytes/sloc. The next step would be to come up with some WAG about what you think you'll have in SLOCs and use your bytes/sloc as a very crude yardstick to give you something only *slightly* better than a WAG at how much memory you'll need. Now its a SWAG instead of a WAG. Its probably better than consulting an ouiji board or tarot cards - just not by a whole lot. If you understand the limitations of what you're doing, you might not be an order of magnitude off when you design the hardware memory limitations. It does raise an interesting problem. If you have to commit to certain parameters early on in the project (such as memory or processor speed) how do you estimate how much you'll need when you don't have the software yet? Even assuming you've got prior experience with similar systems, you really have no good basis in measurement to make estimates until there is some actual software available. Maybe this suggests that software development should start way in advance of hardware decisions. But that has its own problems with respect to time-to-market and other considerations. Everyone can criticize just about any attempt to make measurements and estimates for lots of good reasons. Who could suggest a better alternative for how to make these estimates early on in a project when critical decisions must be made? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Stephen Leake" wrote in message news:uy9n31060.fsf@gsfc.nasa.gov... > > Yes. So once again, bytes/sloc is a non-useful measure. >