natgillin/translations-raw huggingface dataset:
To achieve this, Regular Expressions defines rules for expressing in details a generalization of a string to match. Our example, which we might literally express like this: A line starting with either Henrik or Pernille (possibly following up to 4 blanks or tab characters) followed by a whitespace followed by sa and then either ys or id could be expressed with the following regular expression:
För att åstadkomma detta, definierar reguljära uttryck detaljerade regler för att beskriva en generell sträng som ska matcha. Vårt exempel, som vi kan beskriva så här med ord: En rad som börjar antingen med Henrik eller Pernilla (möjligen efter upp till fyra mellanslag eller tabulatortecken), följt av ett mellanslag, följt av s och sedan antingen äger eller ade, skulle kunna uttryckas med följande reguljära uttryck:
Escaping of course includes the backslash character itself, to literally match a such, you would write\\\\.
Undantag omfattar förstås också bakstrecket själv, för att uttryckligen matcha ett sådant, skulle du skriva\\\\.
Because letters and digits have a logical order, you can abbreviate those by specifying ranges of them: [a-c] is equal to [abc] and [0-9] is equal to [0123456789]. Combining these constructs, for example [a-fynot1-38] is completely legal (the last one would match, of course, either of a, b, c, d, e, f, y, n, o, t, 1, 2, 3 or 8).
Eftersom bokstäver och siffror har en logisk ordning, kan du förkorta dem genom att ange intervall: [a- c] är samma sak som [abc] och [0- 9] är samma sak som [0123456789]. Att kombineras dessa sammansättningar, till exempel med [a- fynot1- 38] är fullständigt riktigt (detta skulle förstås matcha antingen a, b, c, d, e, f, y, n, o, t, 1, 2, 3 eller 8).
It is of course possible to create a negative class matching as anything but To do so put a caret (^) at the beginning of the class:
Det är förstås möjligt att skapa en negativ klass som matchar allting utom. För att göra detta lägg till en hatt (^) först i klassen:
For example, if you want to find two occurrences of the same word separated by a comma and possibly some whitespace, you could write (\\w+), \\s*\\1. The sub pattern \\w+ would find a chunk of word characters, and the entire expression would match if those were followed by a comma, 0 or more whitespace and then an equal chunk of word characters. (The string \\1 references the first sub pattern enclosed in parentheses)
Om du till exempel vill hitta två förekomster av samma ord åtskilda av ett kommatecken och möjligen några blanktecken, skulle du kunna skriva (\\ w+),\\ s *\\ 1. Delmönstret\\ w+ skulle hitta en grupp med ord- tecken, och hela uttrycket skulle matcha om de följdes av ett komma, noll eller flera blanktecken och sedan en likadan grupp med ord- tecken. (Strängen\\ 1 refererar till det första delmönstret inneslutet i parenteser).
When using quantifiers with no maximum, regular expressions defaults to match as much of the searched string as possible, commonly known as greedy behavior.
När kvalificeringar utan maximum används, så matchar reguljära uttryck normalt så mycket av söksträngen som möjligt, ett beteende som ofta kallas för glupskt.
Modern regular expression software provides the means of turning off greediness, though in a graphical environment it is up to the interface to provide you with access to this feature. For example a search dialog providing a regular expression search could have a check box labeled Minimal matching as well as it ought to indicate if greediness is the default behavior.
Modern programvara för reguljära uttryck tillhandahåller en möjlighet att stänga av det glupska beteendet, även om det är det grafiska gränssnittet som måste ge dig tillgång till den här funktionen. En sökdialogruta som tillhandahåller sökning med reguljära uttryck skulle kunna ha en kryssruta som heter Minimal matchning, och borde också ange att glupskt beteende är det normala.
Some assertions actually do 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.
Vissa påståenden har verkligen ett mönster som ska matcha, men den delen av strängen som matchar kommer inte att ingå i resultatet för matchningen av hela uttrycket.
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.
Det här betyder att det matchar till exempel inne i ord: Uttrycket\\ Bin\\ B matchar in i minne men inte i ingång eller Han kom in genom fönstret.
No Author Yet
Ännu ingen författare
The documentation for & kbugbuster; was not finished when & kde; was installed on this computer.
Dokumentationen för & kbugbuster; var inte klar när & kde; installerades på den här datorn.
Original author of the documentation
Ursprunglig författare av dokumentationen
Updates and corrections
Uppdateringar och rättningar
& kcachegrind; is a profile data visualization tool, written using the & kde; environment.
& kcachegrind; är ett visualiseringsverktyg för profileringsdata, som är skrivet för & kde; - miljön.
When developing a program, one of the last steps often involves performance optimizations. As it makes no sense to optimize 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.
När ett program utvecklas, omfattar ett av de sista stegen ofta prestandaoptimering. Eftersom det inte är vettigt att optimera funktioner som sällan används, vilket skulle vara bortkastad tid, måste man veta i vilka delar av programmet som den största delen av tiden går åt.
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 cannot easily attributed, here it is better to generate timestamped event traces. & kcachegrind; cannot visualize this kind of data.
För sekvensiell kod är det ofta tillräckligt att samla statistisk data om programmets beteende under körning, som åtgången tid i funktioner och per kodrad. Det kallas profilering. Programmet körs under övervakning av ett profileringsverktyg, som ger summeringen av en programkörning vid slutet. Däremot, för parallell kod, uppstår prestandaproblem oftast när en processor väntar på data från en annan. Eftersom väntetiden oftast inte enkelt kan fördelas, är det bättre att skapa tidsstämplade händelseföljder. & kcachegrind; kan inte visualisera den sortens data.
After analyzing 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 optimized. Afterwards, the success of the optimization should be verified with another profile run.
Efter att ha analyserat skapad profileringsdata ska det vara enkelt att se utsatta ställen och flaskhalsar i koden. Till exempel kan antaganden om antal anrop kontrolleras, och identifierade kodavsnitt kan optimeras. Efteråt bör optimeringens resultat verifieras med ytterligare en profileringskörning.
To exactly measure the time passed or record the events happening during the execution of a code region (eg; 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.
För att exakt mäta tiden som går eller spela in händelser som inträffar under körning av ett kodavsnitt (t. ex. en funktion) krävs att ytterligare uppmätningskod infogas innan och efter det givna området. Den här koden läser tiden eller en global händelseräknare, och beräknar skillnader. Alltså måste originalkoden ändras innan körning. Det kallas instrumentering. Instrumentering kan göras av programmeraren själv, av kompilatorn eller av körningssystemet. Eftersom intressanta områden ofta är i flera nivåer, påverkar tiden som går åt för mätningen alltid mätresultatet. Därför måste instrumentering göras selektivt och resultaten måste tolkas noggrant. Detta gör förstås prestandaanalys med exakta mätningar till en mycket komplex process.
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 reinitialized 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.
Exakta mätningar är möjliga på grund av räknare i hårdvara (inklusive räknare som ökas när tiden tickar), som tillhandahålls i moderna processorer, och som ökas så fort en händelse inträffar. Eftersom vi vill tilldela händelser till kodavsnitt, skulle vi behöva hantera varje händelse genom att öka en räknare för det aktuella kodavsnittet själva, om inte räknarna fanns. Att göra detta i programvara är förstås inte möjligt. Men med antagandet att distributionen av händelser i källkoden är liknande om man bara tittar på var n: e händelse istället för varje, har en mätmetod som är justerbar med avseende på tiden som går åt för mätningen skapats. Den kallas sampling. Tidsbaserad sampling (TBS) använder tidmätning för att regelbundet titta på programräknaren för att skapa ett histogram av programmets kod. Händelsebaserad sampling (EBS) utnyttjar hårdvaruräknarna i moderna processorer, och använder ett läge där en avbrottshanterare anropas när en räknare går förbi nollvärdet, och skapar ett histogram av motsvarande händelsefördelning. I avbrottshanteraren initieras räknaren alltid om till n i samplingsmetoden. Fördelen med sampling är att koden inte behöver ändras, men det är fortfarande en kompromiss: antagandet ovan är riktigare om n är litet, men ju mindre n är, desto större är tiden som går åt i avbrottshanteraren.
Another measurement method is to simulate things happening in the computer system when executing a given code, & ie; 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 practice. 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.
En annan mätmetod är att simulera det som händer i ett datorsystem när en given kod körs, dvs. körningsstyrd simulering. Simuleringen härleds alltid från en mer eller mindre noggrann modell av datorn. För mycket detaljerade modeller som är nära verkligheten, kan simuleringstiden dock vara oacceptabelt hög i praktiken. Fördelen med simulering är att godtyckligt komplex mätnings - och simuleringskod kan infogas i en given kod utan att störa resultaten. Att göra detta direkt innan körningen (vilket kallas instrumentering vid körning) med det ursprungliga binärprogrammet, är mycket bekvämt för användaren: Ingen omkompilering behövs. Simulering blir användbar om bara delar av en dator simulerats med en enkel modell. En annan fördel är att resultat som skapas av enkla modeller ofta är mycket enklare att förstå: problemet med riktig hårdvara är ofta att resultaten innehåller överlappande effekter från olika delar av datorn.
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 required re-compilation step to prepare the executable, which has to be statically linked. The method used here is compiler-generated instrumentation, 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, & ie; time spent in a function together with all functions called from it.
Mest känt är GCC: s profileringsverktyg gprof. Man måste kompilera programmet med väljaren - pg, köra programmet för att skapa filen gmon. out, som kan översättas till läsbar form med gprof. En nackdel är omkompileringssteget för att förbereda det körbara programmet, som också måste länkas statiskt. Metoden som används här är instrumentering skapad av kompilatorn, som mäter anrop som sker mellan funktioner och motsvarande antal anrop, tillsammans med tidsbaserad sampling, vilket ger ett histogram av tidsdistributionen i koden. Med båda typerna av information är det möjligt att heuristiskt beräkna samlad tid i funktioner, dvs. tiden som går åt i en funktion tillsammans med alla funktioner som anropas från den.
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).
För exakt mätning av händelser som inträffar, finns det bibliotek med funktioner som kan läsa ut hårdvaruprestandaräknare. Mest välkänd är programfixen PerfCtr för & Linux;, och de arkitekturoberoende biblioteken PAPI och PCL. Exakta mätningar behöver ändå instrumentering av koden, som tidigare beskrivits. Antingen använder man biblioteken själv, eller automatiska instrumenteringssystem som ADAPTOR (för instrumentering av FORTRAN källkod) eller DynaProf (kodinjicering via DynInst).
& oprofile; is a system-wide profiling tool for & Linux; using Sampling.
& oprofile; är ett systemprofileringsverktyg för & Linux; som använder sampling.
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.
I många avseenden är ett bekvämt sätt att utföra profilering att använda & cachegrind; eller & callgrind;, vilka är simulatorer som använder ramverket & valgrind; för instrumentering vid körning. Eftersom det inte finns något behov av att komma åt hårdvaruräknare (ofta svårt med dagens & Linux; - installationer), och binärprogram som ska profileras kan lämnas oförändrade, är det ett bra alternativt sätt jämfört med andra profileringsverktyg. Nackdelen med långsammare körning på grund av simuleringen kan reduceras genom att bara utföra simuleringen för intressanta programavsnitt, och kanske bara under några få iterationer av en snurra. Utan instrumentering för mätning och simulering leder & valgrind; s användning bara till en körning som är 3 till 5 gånger långsammare. Dessutom, om bara anropsdiagrammet och anropsantalen är intressanta, kan cachesimuleringen stängas av.
Cache simulation is the first step in approximating real times, since 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, on modern systems. & cachegrind; does cache simulation by catching memory accesses. The data produced includes the number of instruction/ data memory accesses and first- and second-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.
Cachesimulering är det första steget i att approximera realtid, eftersom i moderna system är körtiden mycket känslig för hur så kallade cacher utnyttjas (små och snabba buffrar som snabbar upp upprepade åtkomster till samma celler i huvudminnet). & cachegrind; simulerar cacher genom att lagra minnesaccesser i cacherna. Den data som skapas omfattar antal åtkomster till instruktions - och dataminnet och cachemissar i första och andra nivåns cacher, och den relateras till källkodsrader och funktioner i programmet som kör. Genom att kombinera antal missar, och använda latenstider för missar för typiska processorer, kan en uppskattning av åtgången tid ges.
& 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.
& callgrind; är en utökning av & cachegrind; som bygger upp anropsträdet för ett program i farten, dvs. hur funktionerna anropar varandra och hur många händelser som inträffar när en funktion körs. Dessutom kan den profileringsdata som måste samlas in delas upp enligt trådar och anropskedjans sammanhang. Det kan tillhandahålla profileringsdata på instruktionsnivå för att göra det möjligt att kommentera disassemblerad kod.
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.
Profileringsverktyg skapar typiskt en stor mängd data. Önskan att snabbt bläddra uppåt och neråt i anropsdiagrammet, tillsammans med snabbt byte av sorteringsläge för funktioner och visning av olika händelsetyper, motiverar ett grafiskt gränssnitt för att utföra uppgiften.
& kappname; is a visualization tool 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.
& kappname; är ett visualiseringsverktyg för profileringsdata som uppfyller dessa önskemål. Även om det först programmerats med bläddring i data från & cachegrind; och & calltree; i åtanke, finns det konverteringsprogram tillgängliga för att kunna visa profileringsdata som skapats av andra verktyg. I appendix ges en beskrivning av filformatet som används av & cachegrind; / callgrind;.
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 views for a selected function, namely:
Förutom en lista med funktioner sorterade enligt mätetal över enskild eller samlad kostnad, eventuellt grupperade enligt källkodsfil, delat bibliotek eller C++ klass, erbjuder & kappname; diverse visualiseringsvyer för en vald funktion, närmare bestämt:
a tree-map view, which allows nested-call relations to be visualized, together with inclusive cost metric for fast visual detection of problematic functions,
en trädkarta, som gör det möjligt att visualisera anropsförhållanden i flera nivåer tillsammans med mätetal över samlad kostnad för snabb visuell detektering av problematiska funktioner,
Generate Data to Visualize
Skapa data att visualisera
First, one wants to generate performance data by measuring aspects of the runtime characteristics of an application, using a profiling tool. & kcachegrind; itself does not include any profiling tool, but is good in being used together with & callgrind;, and by using a converter, also can be used to visualize data produced with & oprofile;. Although the scope of this manual is not to document profiling with these tools, the next section provides short quickstart tutorials to get you started.
Först vill man skapa prestandainformation genom att mäta olika aspekter av ett programs beteende under körning, genom att använda ett profileringsverktyg. & kcachegrind; själv inkluderar inte något profileringsverktyg, men är bra på att användas tillsammans med & callgrind;, och kan också användas för att visualisera data som skapats av & oprofile;, genom att använda ett konverteringsprogram. Även om syftet med den här handboken inte är att dokumentera profilering med dessa verktyg, ger nästa avsnitt korta handledningar för att du snabbt ska komma igång.
& callgrind; is a part of valgrind;. Note that it previously was called & calltree;, but that name was misleading.
& callgrind; är en del av valgrind;. Observera att det tidigare kallades & calltree; men det namnet var missvisande.
The most common use is to prefix the command line to start your application with valgrind --tool=callgrind, as in: valgrind --tool=callgrind myprogram myargs At program termination, a file callgrind. out. pid will be generated, which can be loaded into & kcachegrind;.
Den vanligaste användningen är att inleda kommandot för att starta ditt program med valgrind -- tool=callgrind, som med: valgrind -- tool=callgrind mitt_ program mina_ väljare När programmet avslutas skapas filen callgrind. out. pid, som kan laddas i & kcachegrind;.