Avoiding implicit try finally section/fi

From Free Pascal wiki
Jump to: navigation, search

English (en) suomi (fi) Bahasa Indonesia (id) русский (ru)

Epäsuoran try finally lohkon välttäminen

Yleistä

Koodin optimoinnissa se auttaa ymmärtämään, että kääntäjä käärii tiettyjä koodirakenteita epäsuorasti tryfinally-lohkoon. Tämä on tarpeen aina, kun käytetään sellaisia muuttujia, kuten ansiString, variants tai dynaamisia taulukoita jotka edellyttävät initialization ja finalization (esim. kun standardi aliohjelmat initialize ja finalize tarvitaan oikean muistin allokoinnin ja hankitun muistin vapauttamiseksi).

Tällöin kääntäjä varmistaa, että msg: n viitenumero lasketaan asianmukaisesti, kun menettely doSomething poistuu poikkeuksella. Usein tämä voi kuitenkin aiheuttaa merkittäviä haitallisia vaikutuksia tuotetun koodin nopeuteen.

Tämä oli ongelma, joka oli fpc-devel -sähköpostilistan aiheketjussa http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg01367.html TList slowness classes .

Huomaa, että väliaikaiset ansiString-muuttujat voidaan luoda epäsuorasti. Ainoa tapa olla täysin varma siitä, mitä todellisuudessa tehdään, on lukea assemblerin ulostulo.

Mahdolliset ratkaisut

  • Käytetään {$implicitexceptions off}: Varmistetaan, että tämä koskee vain julkaistuja versioita. Virheenjäljitys voi muuttua hankalaksi, kun siirrytään erityisesti muistivuotoihin ja korruptioon.
  • Irrotetaan harvoin käytetty koodi, joka aiheuttaa implisiittisen tryfinally eri aliohjelmiin. (Voidaan käyttää aliohjelmissa aliohjelmia)
  • Käytetään const parametreja arvoparametrien sijaan. Näin vältetään tarve muuttaa viittausosoitusta, mutta tilapäiset muuttujat voivat edelleen olla ongelma.
  • Käytetään globaaleja muuttujia: Sinun on kuitenkin oltava varovainen uusintakysymyksissä, mutta väliaikaiset muuttujat voivat silti olla ongelma.
  • Käytetään ei-viitteellisiä tyyppejä, kuten shortstring.

riskejä ja milloin niitä sovelletaan

Warning-icon.png

Warning: Nämä poikkeuskehykset luodaan syystä. Jos niistä jätetään poikkeus niin koodiin jään muistivuoto mahdollisuus


Vuonna 2007 {$implicitExceptions} lisättiin strutils-käännösyksikköön. Jota sysutils on luultavasti seurannut. Tätä varten noudatettiin seuraavaa lähestymistapaa:

  • Rutiini, joka kutsuu rutiinia, joka nostaa poikkeuksia, on vaarallinen - esim. strToInt, mutta ei strToIntDef.
  • Poikkeuksia aiheuttavat rutiinit on huomioitavia.
  • Hyvin suuret rutiinit eivät ole vaivan arvoista, koska riski ja alhaiset edut - esim. päivämäärän muotoilurutiinit.
  • Desimaalilukujen käyttö voi nostaa poikkeuksia, jotka muunnetaan sysUtils-ohjelmien avulla. En ole varma, onko tämä todellakin riittävä syy, mutta ohitin Desimaalilukujen käytön käyttämällä näitä rutiineja aluksi tästä syystä.

Jos havaitset näitä muutoksia, ota yhteyttä Marcoviin.

Demo-ohjelma

Alla on pieni demo-ohjelma

Sen suorittaessaan osoittaa selvästi, että epäsuoran try … finally välttäminen mhdollistaa koodin suorittamisen paljon nopeammin. Kun suoritin tämän ohjelman järjestelmässäni, sain tuloksen:

time of fooNormal: 141
time of fooFaster: 17
  • Tässä näytetään temppu, jolla vältetään epäsuoria tryfinally - lohkoja (muuttamatta koodin merkitystä tai turvallisuutta) joissakin tapauksissa (kun sinun ei tarvitse tosiasiallisesti käyttää tätä AnsiString/

Variant-tyyppiä/ jotakin muuta tyyppiä joka kerta kun aliohjelmaa kutsutaan mutta vain jos jollakin parametrilla on tietty arvo).


  1. program implicitExceptionDemo(input, output, stderr);
  2.  
  3. // for exceptions
  4. {$mode objfpc}
  5. // data type 'string' refers to 'ansistring'
  6. {$longstrings on}
  7.  
  8. uses
  9.   {$IFDEF UNIX}
  10.     // baseUnix, unix needed only to implement clock
  11.     BaseUnix, Unix,
  12.   {$ENDIF}
  13.     sysUtils;
  14.  
  15. function clock(): int64;
  16.  
  17. var
  18.   {$IFDEF UNIX}
  19.     dummy: tms;
  20.   {$ELSE}
  21.     TS : TTimeStamp;
  22.   {$ENDIF}
  23. begin
  24.   {$IFDEF UNIX}
  25. 	clock := fpTimes(dummy);
  26.   {$ELSE}
  27.    TS:=DateTimeToTimeStamp(Now);
  28.    result := TS.Time;
  29.   {$ENDIF}
  30. end;
  31.  
  32.  
  33.  
  34. // Note: when fooNormal and fooFaster are called
  35. //       i is always >= 0, so no exception is ever actually raised.
  36. // So string constants SNormal and SResString are not really used.
  37.  
  38. procedure fooNormal(i: integer);
  39. var
  40. 	s: string;
  41. begin
  42. 	if i = -1 then
  43. 	begin
  44. 		s := 'Some operation with AnsiString';
  45. 		raise exception.create(s);
  46. 	end;
  47. end;
  48.  
  49. procedure fooFaster(i: integer);
  50. 	procedure raiseError;
  51. 	var
  52. 		s: string;
  53. 	begin
  54. 		s := 'Some operation with AnsiString';
  55. 		raise exception.create(s);
  56. 	end;
  57. begin
  58. 	if i = -1 then
  59. 	begin
  60. 		raiseError;
  61. 	end;
  62. end;
  63.  
  64.  
  65. // M A I N =================================================
  66. const
  67. 	testCount = 10000000;
  68. var
  69. 	i: integer;
  70. 	start: int64;
  71. begin
  72. 	start := clock();
  73. 	for i := 0 to testCount do
  74. 	begin
  75. 		fooNormal(i);
  76. 	end;
  77. 	writeLn('time of fooNormal: ', clock() - start);
  78.  
  79. 	start := clock();
  80. 	for i := 0 to testCount do
  81. 	begin
  82. 		fooFaster(i);
  83. 	end;
  84. 	writeLn('time of fooFaster: ', clock() - start);
  85. end.

Laittamalla raiseError toiseen näkyvyyteen fooFaster aliohjelmassa, keskeysten käsittely ei tule osaksi pääkäyttöistä suoritusosaa.