natgillin/translations-raw huggingface dataset:
Påstande tillader et regulært udtryk kun at match under visse kontrollerede betingelser.
Assertions allows a regular expression to match only under certain controlled conditions.
En behøver ikke et tegn for at matche, den undersøger snarere omgivelserne for en mulig match før den anerkender den. For eksempel ordgrænse - påstanden forsøger ikke at finde et ikke ord- tegn overfor et på dens plads, i stedet sørger den for at der ikke er et ord- tegn. Dette betyder at påstanden kan matche hvor der ikke er noget tegn, & ie; ved slutningen af en søgt streng.
An assertion does not need a character to match, it rather investigates the surroundings of a possible match before acknowledging it. For example the word boundary assertion does not try to find a non word character opposite a word one at its position, instead it makes sure that there is not a word character. This means that the assertion can match where there is no character, & ie; at the ends of a searched string.
Visse påstande har rent faktisk ikke noget mønster at matche, men den del af strengmatchningen vil ikke blive en del af resultatet af matchningen for det fulde udtryk.
Some assertions actually does have a pattern to match, but the part of the string matching that will not be a part of the result of the match of the full expression.
Regulære udtryk som dokumenteret her understøtter følgende udtryk:
Regular Expressions as documented here supports the following assertions:
^ (karet: begyndelsen af streng)
^ (caret: beginning of string)
Matcher begyndelsen af den søgte streng.
Matches the beginning of the searched string.
Udtrykket ^Inger vil matche ved Inger i strengen Inger, hej! men ikke i Hej, Inger!
The expression ^Peter will match at Peter in the string Peter, hey! but not in Hey, Peter!
$(slutning af streng)
$(end of string)
Matcher slutningen af den søgte streng.
Matches the end of the searched string.
Udtrykket du\\? $vil matche ved det sidste du i strengen Du gjorde det ikke, gjorde du? men ingen steder i Du gjorde det ikke, vel?
The expression you\\? $will match at the last you in the string You did n't do that, did you? but nowhere in You did n't do that, right?
\\ b (ordgrænse)
\\b (word boundary)
Matcher hvis der er et ord- tegn på den ene side og et ikke- ord- tegn på den anden.
Matches if there is a word character at one side and not a word character at the other.
Dette er nyttigt for at finde ord- afslutninger, for eksempel begge ender for at finde et helt ord. Udtrykket\\ ben\\ b vil matche det en der er for sig selv i strengen Der var en der kom ind gennem vinduet, men ikke det en der er i gennem.
This is useful to find word ends, for example both ends to find a whole word. The expression \\bin\\b will match at the separate in in the string He came in through the window, but not at the in in window.
\\ B (ikke- ord- grænse)
\\B (non word boundary)
Matcher hvor\\ b ikke gør.
Matches wherever \\b does not.
Det betyder at det for eksempel vil matche inde i ord: Udtrykket\\ Bel\\ B vil matche ved el i heldig men ikke i alligevel eller Mon du elsker mig.
That means that it will match for example within words: The expression \\Bin\\B will match at in window but not in integer or I 'm in love.
(? =PATTERN) (Positiv fremadskuen)
(? =PATTERN) (Positive lookahead)
En fremadskuende påstand kigger på den del af strengen der følger en mulig match. Den positive fremadskuen vil forhindre strengen i at matche hvis teksten der følger den mulige match ikke matcher et PATTERN i påstanden, men den tekst der matches derved vil ikke blive inkluderet i resultatet.
A lookahead assertion looks at the part of the string following a possible match. The positive lookahead will prevent the string from matching if the text following the possible match does not match the PATTERN of the assertion, but the text matched by that will not be included in the result.
Udtrykket skole (? =\\ w) vil matche ved skole i skolelærer men ikke ved Skulker du fra din skole?
The expression handy(? =\\w) will match at handy in handyman but not in That came in handy!
(?! PATTERN) (Negativ fremadskuen)
(? !PATTERN) (Negative lookahead)
Den negative fremadskuen forhindrer en mulig match i at blive anerkendt hvis den følgende del af den søgte streng ikke matcher dens PATTERN.
The negative lookahead prevents a possible match to be acknowledged if the following part of the searched string does match its PATTERN.
Udtrykket const\\ w+\\ b (?!\\ s* amp;) vil matche ved const char i strengen const char * foo men den ikke kan matche const QString i const QStringamp; bar fordi amp; matcher den negative fremadskuen påstandsmønster.
The expression const \\w+\\b(? !\\s*amp;) will match at const char in the string const char* foo while it can not match const QString in const QStringamp; bar because the amp; matches the negative lookahead assertion pattern.
& kbugbuster; - håndbogen
The & kbugbuster; Handbook
& kbugbuster; er en del af kdesdk- pakken.
& kbugbuster; is part of the kdesdk package.
Dokumentation for & kappname; var desværre ikke færdig da & kde; blev installeret på denne computer.
The documentation for & kappname; was not finished when & kde; was installed on this computer.
Hvis du har brug for hjælp, så tjek venligst kde; 's hjemmeside for opdateringer, eller indsend dine spørgsmål til kde;' s bruger e- mail- liste.
If you need help, please check The & kde; Website for updates, or by submitting your question to The & kde; User Mailing list.
& kcachegrind; - håndbogen
The & kcachegrind; Handbook
Josef. Weidendorfer@ gmx. de
Josef. Weidendorfer@gmx. de
& rune. laursen. role;
Andrew Coles andrew_coles@yahoo. co. uk Conversion to British English
& Josef. Weidendorfer;
Josef Weidendorfer
& kcachegrind; er et værtøj til visualisering af profileringsdata, skrevet til & kde; - miljøet.
& kcachegrind; is a profile data visualisation tool, written using the & kde; environment.
Cachegrind
Cachegrind
Profilering
Profiling
& kappname; er en browser til data produceret af profileringsværktøjer. Dette kapitel forklarer hvad profilering er til for, hvordan det gøres og giver nogle eksempler på nogle profileringsværktøjer der er til rådighed.
& kappname; is a browser for data produced by profiling tools. This chapter explains what profiling is for, how it is done, and gives some examples of profiling tools available.
Når du udvikler et program, er et af de sidste skridt, at gøre det så hurtigt som muligt (men stadigvæk rigtigt). Du vil ikke sløse tiden væk på at optimere funktioner som sjældent bruges. Derfor skal du vide i hvilke dele af programmet den største del af tiden bruges.
When developing a program, one of the last steps often involves performance optimisations. As it makes no sense to optimise functions rarely used, because that would be a waste of time, one needs to know in which part of a program most of the time is spent.
For sekventiel kode er det ofte tilstrækkeligt at samle statistiske data om programmets karakteristika ved kørselstidspunktet, som f. eks. tiden der forbruges i funktioner og kodelinjer. Dette kaldes profilering. Programmet køres under kontrol af et profileringsværktøj, som giver en opsummering i slutningen af programkørslen. I modsætning til dette skyldes ydelsesproblemer i parallel kode, ofte at en processor venter på data fra en anden. Da denne ventetid er svær at henføre til programkode, er det bedre at generere tidsstemplede begivenhedsspor. & kcachegrind; kan ikke visualisere denne type af data.
For sequential code, collecting statistical data of the programs runtime characteristic like time numbers spent in functions and code lines usually is enough. This is called Profiling. The program is run under control of a profiling tool, which gives the summary of an execution run at the end. In contrast, for parallel code, performance problems typically are caused when one processor is waiting for data from another. As this waiting time usually can not easily attributed, here it is better to generate timestamped event traces. KCachegrind can not visualise this kind of data.
Efter en analyse af de producerede profileringsdata, er det nemt at finde problemfyldte områder og flaskehalse i koden. F. eks kan antagelser om antallet af kald kontrolleres og de identificerede kodeområder kan optimeres. Efter ændringen bør optimeringens effekt verificeres på ny, med endnu en profileringskørsel.
After analysing the produced profile data, it should be easy to see the hot spots and bottlenecks of the code: for example, assumptions about call counts can be checked, and identified code regions can be optimised. Afterwards, the success of the optimisation should be verified with another profile run.
Profileringsmetoder
Profiling Methods
For præcist at kunne måle den forbrugte tid eller begivenheder der sker i et kodeområde, f. eks. en funktion, er det nødvendigt at indsætte yderligere målekode før og efter det givne område. Denne kode læser tiden eller en global begivenhedstæller og beregner forskelle. Derfor skal den oprindelige kode ændres før kørslen. Dette kaldes instrumentering. Instrumentering kan udføres af programmøren selv, oversætteren eller af kørselssystemet. Eftersom interessante kodeområder normalt er indlejrede påvirker selve målingen altid måleresultaterne i sig selv. Derfor skal instrumentering altid udføres selektivt og resultaterne skal fortolkes med forsigtighed. Dette gør naturligvis ydelsesanalyse vha. eksakt måling, til en meget vanskelig proces.
To exactly measure the time passed or record the events happening during the execution of a code region (e. g. a function), additional measurement code needs to be inserted before and after the given region. This code reads the time, or a global event count, and calculates differences. Thus, the original code has to be changed before execution. This is called instrumentation. Instrumentation can be done by the programmer itself, the compiler, or by the runtime system. As interesting regions usually are nested, the overhead of measurement always influences the measurement itself. Thus, instrumentation should be done selectively and results have to be interpreted with care. Of course, this makes performance analysis by exact measurement a very complex process.
Præcis måling er mulig fordi hardwaretællere (inklusive tællere der optælles én gang pr. klokpuls), som er til rådighed i moderne processorer, optælles hver gang der sker en begivenhed. Da vi gerne vil henføre begivenheder til kodeområder, ville vi uden tællerne, være nødt til at håndtere hver eneste begivenhed, ved selv at skulle optælle en tæller for kodeområdet. At gøre dette i software er naturligvis ikke muligt. Under antagelsen af at der er en ens fordeling af begivenheder i kildekoden, når man kun ser på hver n' te begivenhed i stedet for hver eneste, har vi konstrueret en målemetode som er mulig at finindstille mht. omkostninger. Dette kaldes at sample. Tidsbaseret sampling benytter en tæller til jævnligt at se på programtælleren til at lave et histogram af programkoden. Begivenhedsbaseret sampling udnytter hardwaretællere i moderne processorer og bruger en tilstand hvor en interrupt håndtering kaldes ved tællerunderløb, hvorved der genereres et histogram af den tilsvarende fordeling f begivenheder. I håndteringen gen- initialiseres begivenhedstælleren altid til samplingmetodens n. Fordelen ved sampling er at koden ikke skal ændres. Det er dog stadig et kompromis. Den ovenstående antagelse bliver mere korrekt når n er et lille tal, men jo mindre værdi af n, jo højere er omkostningerne til interrupthåndteringen.
Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software is, of course, not possible; but, on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, a measurement method whose overhead is tunable has been developed: it is called Sampling. Time Based Sampling (TBS) uses a timer to regularly look at the program counter to create a histogram over the program code. Event Based Sampling (EBS) exploits the hardware counters of modern processors, and uses a mode where an interrupt handler is called on counter underflow to generate a histogram of the corresponding event distribution: in the handler, the event counter is always reinitialised to the 'n 'of the sampling method. The advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if n is small, but the smaller the n, the higher the overhead of the interrupt handler.
Endnu en målemetode er at simulere det der sker i computersystemet når noget given kildekode eksekveres, dvs. kørselsdrevet simulering. Denne simulering er naturligvis altid afledt af en mere eller mindre præcis model af maskinen. Til meget detaljerede modeller, der kommer meget tæt på virkeligheden, kan simuleringstiden i praksis være uacceptabelt stor. Fordelen er at vilkårligt kompleks målings - og simuleringskildekode kan indsættes i noget given kildekode uden at påvirke resultaterne. At gøre dette lige før kørslen (kaldes, kørselstidsinstrumentering), ved at bruge den oprindelige kørbare, er meget komfortabelt for brugeren. Metoden er brugbar når man kun simulerer dele af en maskine og med en simpel model. Desuden er resultater produceret af en simpel model meget lettere at tolke. Problemet med rigtig hardware, er at resultaterne ofte viser overlappende effekter fra forskellige dele af maskinen.
Another measurement method is to simulate things happening in the computer system when executing a given code, i. e. execution driven simulation. The simulation is always derived from a more or less accurate machine model; however, with very detailed machine models, giving very close approximations to reality, the simulation time can be unacceptably high in practise. The advantage of simulation is that arbitrarily complex measurement/ simulation code can be inserted in a given code without perturbing results. Doing this directly before execution (called runtime instrumentation), using the original binary, is very comfortable for the user: no re-compilation is necessary. Simulation becomes usable when simulating only parts of a machine with a simple model; another advantage is that the results produced by simple models are often easier to understand: often, the problem with real hardware is that results include overlapping effects from different parts of the machine.
Profileringsværktøjer
Profiling Tools
Mest kendt er GCC' s profileringsværktøj gprof. Du skal kompilere programmet med flaget - pg, køre programmet for at oprette filen gmon. out, som kan oversættes til læsbar form med gprof. En ulempe er kompileringsskridtet for at forberede det kørbare program, som også skal linkes statisk. Denne metode kaldes oversættergenereret instrumentering. Den måler kaldbuer der sker blandt funktioner og i henhold til kaldtællinger i forbindelse med tidsbaseret sampling, der giver et histogram over tidsfordelingen i koden. Ved at udnytte begge typer oplysninger, er det muligt, heuristisk at beregne iberegnet tid i funktioner, dvs. tiden forbrugt i en funktion inklusive alle funktioner der kaldes fra denne funktion
Most known is the GCC profiling tool gprof: One needs to compile the program with option -pg; running the program generates a file gmon. out, which can be transformed into human-readable form with gprof. One disadvantage is the needed re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumention - which measures call arcs happening among functions and corresponding call counts - in conjunction with TBS - which gives a histogram of time distribution over the code. Using both pieces of information, it is possible to heuristically calculate inclusive time of functions, i. e. time spent in a function together with all functions called from it.
For præcis måling af begivenheder, eksisterer der biblioteker med funktioner, der er i stand til at udlæse hardwareydelsestællere. De mest kendte her er PerfCtr patchen til & Linux; og de arkitekturuafhængige biblioteker PAPI og PCL. Der er dog stadig behov for præcise målinger som forklaret i det ovenstående. Enten benytter man bibliotekerne for sig selv eller også benytter man automatiserede instrumenteringssystemer som ADAPTOR (til FORTRAN kildekodedokumentation) eller DynaProf (kodeindsættelse via. DynInst).
For exact measurement of events happening, libraries exist with functions able to read out hardware performance counters. Most known here is the PerfCtr patch for Linux, and the architecture independent libraries PAPI and PCL. Still, exact measurement needs instrumentation of code, as stated above. Either one uses the libraries itself or uses automatic instrumentation systems like ADAPTOR (for FORTRAN source instrumentation) or DynaProf (code injection via DynInst).
& oprofile; er et profileringsværktøj til & Linux;. Det benytter sampling.
& oprofile; is a system-wide profiling tool for Linux using Sampling.
På mange måder er brug af & cachegrind; eller & callgrind;, en behagelig måde at udføre profilering på. De er begge simulatorer der benytter kørselstidsinstrumenteringsskelettet & valgrind;. Fordi der ikke er noget behov for at tilgå hardwaretællere (ofte vanskeligt med dagens & Linux; - distributioner) og fordi de binære filer der skal profileres ikke behøver ændringer, er det et godt alternativ til andre profileringsværktøjer. Ulempen ved hastighedstab ved simulering, kan reduceres ved at udføre simuleringen, kun på de interessante steder i programmet og måske kun i et par iterationer af en løkke. Uden målings - eller simuleringsinstrumentering, ses der ved brug af & valgrind; kun et hastighedstab i størrelsesordenen 3- 5. Når der kun benyttes kaldgrafen og kaldtælling kan cachesimulatoren slås helt fra.
In many aspects, a comfortable way of Profiling is using Cachegrind or Callgrind, which are simulators using the runtime instrumentation framework & valgrind;. Because there is no need to access hardware counters (often difficult with today 's Linux installations), and binaries to be profiled can be left unmodified, it is a good alternative to other profiling tools. The disadvantage of simulation - slowdown - can be reduced by doing the simulation on only the interesting program parts, and perhaps only on a few iterations of a loop. Without measurement/ simulation instrumentation, Valgrind 's usage only has a slowdown factor in the range of 3 to 5. Also, when only the call graph and call counts are of interest, the cache simulator can be switched off.
Cachesimulering er det første skridt på vejen til ca. realtider, eftersom kørselstiden på moderne systemer, er meget følsom overfor udnyttelsen af cache, små hurtige buffere, som accelererer gentagen tilgang til samme hukommelsesceller. & cachegrind; udfører cachesimulering ved at opfange hukommelsestilgang. De data der produceres, omfatter antallet af instruktioner, adgange til instruktion/ datahukommelse og ikke ramt cache i første og andetniveaus cacher og relaterer det til kildekodelinjer og funktioner i programmet som kører. Ved at kombinere disse ikke ramt- tællinger ved brug af typisk ikke ramt- latens, kan den forbrugte tid estimeres.
Cache simulation is the first step in approximating real times; as, on modern systems, runtime is very sensitive to the exploitation of so called caches (small and fast buffers which accelerate repeated accesses to the same main memory cells.) & cachegrind; does cache simulation by catching memory accesses. The data produced includes the number of instruction/ data memory accesses and 1st/ 2nd level cache misses, and relates it to source lines and functions of the run program. By combining these miss counts, using miss latencies from typical processors, an estimation of spent time can be given.
& callgrind; er en udvidelse af & cachegrind; der opbygger kaldgrafen for et program uden videre & ie; hvordan funktionerne kalder hinanden og hvor mange begivenheder der sker mens en funktion køres. Desuden kan de profildata der skal indsamles, blive adskilt af tråde og kaldkæde- sammenhænge. Den kan sørge for profilering af data på instruktionsniveau for at tillade annotering af disassembled kode.
Callgrind is an extension of & cachegrind; that builds up the call graph of a program on-the-fly, & ie; how the functions call each other and how many events happen while running a function. Also, the profile data to be collected can separated by threads and call chain contexts. It can provide profiling data on an instruction level to allow for annotation of disassembled code.
Visualisering
Visualisation
Profileringsværktøjer producerer typisk store mængder af data. Ønsket om nemt at kunne browse op og ned i kaldgrafen, sammen med hurtig skift i sorteringen af funktioner og visning af forskellige begivenhedstyper, tilskynder til et program med en grafisk brugerflade.
Profiling tools typically produce a large amount of data. The wish to easily browse down and up the call graph, together with fast switching of the sorting mode of functions and display of different event types, motivates a GUI application to accomplish this task.
& kappname; er visualisering af profildata og opfylder dermed disse ønsker. Selvom det er oprindelig er programmeret med browsing af data fra & cachegrind; og & calltree; in mente, er der konvertere til rådighed der kan vise profildata fra andre værktøjer. I appendikset gives der en beskrivelse af & cachegrind; / callgrind; filformatet.
& kappname; is an visualisation for profile data fulfilling these wishes. Despite being programmed first with browsing the data from & cachegrind; and & calltree; in mind, there are converters available to be able to display profile data produced by other tools. In the appendix, a description of the Cachegrind/ Callgrind file format is given.
Udover en liste af funktioner sorteret i henhold til eksklusiv - eller inklusivomkostningsmetrik og efter valg, grupperet efter kildefil, delt bibliotek eller C++- klasser, & kappname; er der også mulighed for forskellige grafvisninger for en valgt funktion.
Besides a list of functions sorted according exclusive or inclusive cost metrics, and optionally grouped by source file, shared library or C++ class, & kappname; features various visualisation views for a selected function, namely
en kaldgrafvisning, som viser en sektion af kaldgrafen omkring den markerede funktion
a call-graph view, which shows a section of the call graph around the selected function,
en træ- kort- visning som tillader en at visualisere indlejrede kaldrelationer til hinanden, med inklusivomkostningsmetrik til hurtig visuel detektion af problemfyldte funktioner,
a tree-map view, which allows nested-call relations to be visualised, together with inclusive cost metric for fast visual detection of problematic functions,
kildekode og disassemblerannotationsvisninger, der giver mulighed for at se detaljer af omkostninger relativt til kildekodelinjer og assemblerinstruktioner.
source code and disassembler annotation views, allowing to see details of cost related to source lines and assembler instructions.
Brug af & kcachegrind;
Using & kcachegrind;
Opret data til visning
Generate Data to Visualise