软件的性能设计(一)接口设计对软件性能的影响

原创 2001年05月23日 15:08:00

           软件的性能设计(一)接口设计对软件性能的影响 
       刘彦清·yesky

  性能方面的问题有好多种。最容易修正的一种是,在执行一项计算任务时使用了一个性能不好的算法,例如,在对数目很多的数据进行排序时采用了起泡算法,每次使用时对一个经常使用的数据项进行计算而不是将它保存起来,这些问题一般我们都能很容易发现,而且一旦发现后,都能很方便地进行改正。然而,许多Java程序性能方面的问题都是是由一些比较深奥的、不容易修改的代码━━程序组件的接口设计引起的。

  大多数的程序都是由内部人员开发的或从外部购买的组件"组装"而成的。即使软件不完全依赖于原有的组件,面向对象的设计过程也使得应用程序在开发时采用组件形式,因为这样可以简化程序的设计、开发和调试方面的工作。尽管采用组件的好处是不可否认的,我们还应该意识到组件的接口会对使用它们的程序的性能和运行状态产生重大的影响。

  也许会有读者问,接口跟性能有什么关系?一个类的接口不但定义了类可以完成的功能,而且还定义了它的对象创建行为和使用它所需要调用的方法的顺序,一个类如何定义它的构造器和方法会影响这个对象是否可以重用,是它本身的方法创建还是要求其客户创建中间对象,客户要使用这个类需要调用多少个方法。

  所有这些因素都会影响到程序的性能。Java软件性能管理方面的基本原理之一是:避免创建过多的对象。这并不意味着你不能创建任何对象从而不充分利用面象对象语言带来的诸多好处,而是说在开发对性能敏感的代码时需要对对象的创建保持谨慎。对象创建的代价相当高昂,我们应该在对性能敏感的软件中尽量避免创建临时或中间对象。

  在处理字符的程序中,String类是引起对象创建的最大源。因为String类是不可变的,每当一个String类的对象被修改或构造时,都会创建一个新的对象。因此,一个具有性能意识的编程人员总是避免过多地使用String类对象。然而,尽管你在编程中尽量避免使用String对象,还是会经常发现使用的组件接口必须使用String对象,因此,你不可能不使用String类对象。

  例子:表达式的匹配

  作为一个例子,可以假设你在编写一个名字为MailBot的邮件服务器。MailBot需要处理每个邮件顶部的MIME头部━━例如发送日期或者发送者的邮件地址,它将通过使用一个匹配表达式的组件处理MIME头部,以使这一处理过程会更简单一些。它把输入的字符放在一个字符缓冲区中,通过对缓冲区进行索引处理标题。由于MailBot将调用这一表达式匹配子程序来处理每一个标题,因此这个匹配子程序的性能将十分地重要。

  我们首先来看一个性能十分低下的表达式匹配类的接口:

  public class AwfulRegExpMatcher {

   /**创建一个给定表达式的匹配过程,它将对给定的字符串进行处理*/

   public AwfulRegExpMatcher(String regExp, String inputText);

   /**找到针对输入文本的下一个匹配模式,如果匹配,返回匹配的文本,否则返回一个空字符 */

   public String getNextMatch();

   }

即使这个类采用了一个很高效的匹配算法,大量调用它的程序的性能也不会很好。因为匹配器对象是与输入文本捆绑在一起的,每次调用它时,都需要首先生成一个新的匹配器对象。由于我们的目标是减少不必要的对象创建工作,实现对匹配过程代码的重用应该是一个良好的开端。

  下面的这个类定义了匹配器的另一种可能的接口,它允许匹配器重用,但性能仍然不够好:

  public class BadRegExpMatcher {

   public BadRegExpMatcher(String regExp);

   /** 试图针对输入文本匹配指定的表达式,如果匹配则返回匹配的文本,否则返回一个空白字符串*/

   public String match(String inputText);

   /** 得到下一个匹配的字符,否则返回一个空白字符*/

   public String getNextMatch();

  }

避开返回的匹配子表达式等敏感的表达式匹配问题不谈,这个类的定义有什么问题吗?如果仅仅从其功能方面看,它没有任何问题,但如果从性能方面来考虑,则它存在许多问题。首先,匹配器要求其调用者创建一个String类来表示被匹配的文本。MailBot应该尽量避免生成String对象,但当它发现一个需要处理的标题时,它必须创建一个String对象供BadRegExpMatcher调用:

  BadRegExpMatcher dateMatcher = new BadRegExpMatcher(...);

   while (...) {

    ...

    String headerLine = new String(myBuffer, thisHeaderStart,

      thisHeaderEnd-thisHeaderStart);

    String result = dateMatcher.match(headerLine);

    if (result == null) { ... }

  }

  其次,即使MailBot仅仅需要得到是否匹配的返回信息,而无需得到匹配的文本,匹配器也会返回一个匹配的字符串。这意味着为了简单地使用BadRegExpMatcher来验证一个特定格式的日期标题,你也必须创建二个 String对象━━供匹配器使用的输入文本和匹配结果文本。创建二个对象似乎不会对性能产生重大影响,但如果必须为MailBot处理的每条邮件的标题创建二个对象,就可能严重地影响程序的性能。这一问题并不出在MailBot本身的设计上,而是出在BadRegExpMatcher的设计上。

  注意:不返回String对象而返回一个"轻量级"的Match对象也不会在性能上带来很大的改进。尽管创建一个Match对象的代价要比创建一个String对象的代价低一些,它还是会产生一个char数组,并拷贝数据,仍然创建了一个对调用者并非必需的临时性的对象。

  BadRegExpMatcher只接受它需要的输入数据类型,而不是可以接受我们方便提供的数据类型,仅就这一点,它就非常不理想。使用BadRegExpMatcher还会带来别的危害,其中的一个潜在的危害是这样将对MailBot的性能带来更多的影响。尽管在处理邮件的标题时必须避免使用Strings,但又必须创建许多的Strings对象供BadRegExpMatcher使用,因此你可能放弃不使用String对象的目标,而更加不受限制地使用它。一个设计不恰当的组件会影响使用它的程序的性能,即使以后找到了一个无需使用String对象的表达式组件,整个程序仍然会受到影响。
 
一个恰当的接口

  如何定义BadRegExpMatcher才能避免上述的问题呢?首先,BadRegExpMatcher应该不指定其输入文本的格式,它应该能够接受其调用者可以高效地提供的任何一种数据类型。其次,它不应该为匹配结果自动地生成一个String对象,只需要返回足够的信息让调用者来决定是否需要生成匹配结果字符串。(也可以提供一个方法来完成这一任务,但这并非是必需的。)一个性能比较好的接口应该是这样的:

  class BetterRegExpMatcher {

    public BetterRegExpMatcher(...);

    /** 使匹配器可以接受多种格式的输入━━ String对象、字符数组、字符组数的子集,如果不匹配,返回-1;如果匹配,则返回开始匹配的偏移地址。*/

    public int match(String inputText);

    public int match(char[] inputText);

    public int match(char[] inputText, int offset, int length);

    /** 如果匹配,则返回匹配的长度;如果不是完全匹配,则调用程序应该能够从匹配的偏移处生成匹配的字符串 */

    public int getMatchLength();

    /** 如果调用程序需要,就可以很方便地得到匹配字符串的子程序 */

    public String getMatchText();

   }

  新的接口消除了调用者将输入文本转化为匹配子程序所要求的格式的需求。MailBot可以用如下的方式调用match():

  int resultOffset = dateMatcher.match(myBuffer, thisHeaderStart, thisHeaderEnd-thisHeaderStart);

  if (resultOffset < 0) { ... }

  这样就既达到了设计目标又没有创建任何新的对象,另外,它的接口设计也体现了Java所倡导的"多而简单的方法"的设计思想。

  创建对象对性能的精确影响取决于match()完成的工作量。通过创建和对二个不作任何实际工作的表达式匹配程序类的运行进行计时,就会发现它们在性能上存在着巨大的差异,在Sun 1.3 JDK中,使用BetterRegExpMatcher类的上述代码的运行速度比使用BadRegExpMatcher类快50倍。通过简单地支持子串匹配,BetterRegExpMatcher的运行速度就可以比BadRegExpMatcher快5倍。

架构设计中影响性能的因素及解决方案

性能(performance)设计非常重要,对于服务器端实时交易系统来说系统性能的重要性不言而喻,对客户端软件来说性能好的软件也会获得良好的用户体验,从而给用户留下高质量软件的良好印象。因此在进行架构...
  • bzhxuexi
  • bzhxuexi
  • 2015年06月15日 09:54
  • 1098

软件架构设计之一:系统性能评价

一、本章要点 1)性能计算(响应时间、吞吐量、TAT) 2)性能设计(系统调整、Amdahl解决方案、响应特性、负载均衡)。 3)性能指标(SPEC-Int、SPEC-Fp、TPC、Gibsonmix...
  • slowwind2007_lishu
  • slowwind2007_lishu
  • 2013年07月18日 22:13
  • 1713

软件接口设计

软件接口设计 《构建可扩展的Web站点》主要介绍了Web应用程序的概念、体系结构、硬件需求、开发环境的原则及国际化、本地化和Unicode等基本内容,本文是软件接口设计。 AD:51CTO ...
  • sanjiaozhen
  • sanjiaozhen
  • 2016年11月26日 17:27
  • 1060

软件接口设计 六大原则

转载自 http://www.cnblogs.com/zfc2201/p/3423370.html 一.单一职责原则 Single Responsibility Principle, ...
  • u010820135
  • u010820135
  • 2016年06月10日 17:41
  • 2854

实时软件的可靠性设计

随着实时软件在可靠性和安全性要求极高的环境和系统中的广泛使用,对软件可靠性的依赖正在以前所未有的速度增长,实时软件的可靠性设计与保证在实时系统中占据着越来越重要的位置。可靠性是实时软件的一个重要指标。...
  • yuyin86
  • yuyin86
  • 2013年11月24日 01:33
  • 3905

数据库的架构设计与性能优化

本文首发于阿里云&《程序员》杂志联合出品的《凌云》专刊中。 作者: 杭州湖畔网络技术经理 王鑫鹏 杭州湖畔网络技术有限公司是一家专业提供SaaS化电商ERP服务的创业公司,主要用户群体为经...
  • liu870915
  • liu870915
  • 2016年07月05日 15:07
  • 1376

软件性能测试完整指南

译文 | 软件性能测试完整指南 作者 | Angela Stringfellow 来源 | DZone 原文 | https://dzone.com/articles/a-com...
  • abdstime
  • abdstime
  • 2017年05月26日 13:50
  • 575

性能测试之场景设计

Load runner Controller来管理和维护场景,可以在一台工作站控制一个场景中的所有虚拟用户(Vuser)。执行场景时,Controller会将该场景中的每个Vuser分配给一个负载生成...
  • Tongdingsidong
  • Tongdingsidong
  • 2017年05月19日 15:42
  • 601

如何写软件概要设计?

软件概要设计做什么,怎么做 一、软件设计一般流程: 1、先前的软件需求分析阶段,已经搞清楚了 “要解决什么问题”,并输出了《软件需要说明书》。这时一切都是理想。 2、现在进入概要设计阶段,重点...
  • NoMasp
  • NoMasp
  • 2015年12月05日 16:15
  • 14855

性能测试中的测试模型设计(图)

可谓是老生常谈的话题,既然是常谈,不妨再谈谈。   今天和大家分享的是一个相对宽泛的设计思路,有兴趣的朋友可以再补充和细化。在以往的模型设计中,我一般会遵循这个设计步骤:信息调研—场景分析...
  • jiangbqing
  • jiangbqing
  • 2017年02月16日 11:38
  • 594
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件的性能设计(一)接口设计对软件性能的影响
举报原因:
原因补充:

(最多只允许输入30个字)