Avoiding implicit try finally section/fi

From Lazarus wiki

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 try finally - 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.