gnome-devel-docs master - en to el translation catalogue (92 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
el: Οι αναζητήσεις δίσκου θεωρούνται επιβλαβής

note: (itstool) path: page/p (itstool) path: section/p
en: Disk seeks are one of the most expensive operations you can possibly perform. You might not know this from looking at how many of them we perform, but trust me, they are. Consequently, please refrain from the following suboptimal behavior:
el: Οι αναζητήσεις του δίσκου είναι από τις ποιο δαπανηρές διαδικασίες που μπορείτε ενδεχομένως να εκτελέσετε. Μπορεί να μην το καταλάβετε αυτό απλά εξετάζοντας πόσες από αυτές εκτελείτε, αλλά πιστέψτε μας, είναι πολλές. Συνεπώς, παρακαλώ να αποφεύγεται την ακόλουθη μη-βέλτιστη συμπεριφορά:

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
el: Τοποθετώντας πολλά μικρά αρχεία παντού στον δίσκο.

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
el: Άνοιγμα, δηλώσεις, και ανάγνωση πολλών μικρών αρχείών παντού στον δίσκο.

note: (itstool) path: item/p
en: Doing the above on files that are laid out at different times, so as to ensure that they are fragmented and cause even more seeking.
el: Κάνοντας τα ανωτέρω σε αρχεία που δημιουργήθηκαν σε διαφορετικούς χρόνους, ώστε να εξασφαλιστεί ότι είναι τεμαχισμένα και να προκαλούν ακόμη περισσότερη αναζήτηση.

note: (itstool) path: item/p
en: Doing the above on files that are in different directories, so as to ensure that they are in different cylinder groups and cause even more seeking.
el: Κάνοντας τα ανωτέρω σε αρχεία που είναι σε διαφορετικούς καταλόγους, ώστε να εξασφαλιστεί ότι βρίσκονται σε διαφορετικές ομάδες κυλίνδρων και έτσι να προκαλεί ακόμη περισσότερη αναζήτηση.

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
el: Επαναλαμβανόμενη εκτέλεση των ανωτέρω όταν θα έπρεπε να γίνει μια μόνο φορά.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
el: Τρόποι με τους οποίους μπορείτε να βελτιστοποιήσετε τον κώδικά σας για είναι φιλικός με τις αναζητήσεις:

note: (itstool) path: item/p
en: Consolidate data into a single file.
el: Παγιώστε τα δεδομένα σε ένα ενιαίο αρχείο.

note: (itstool) path: item/p
en: Keep data together in the same directory.
el: Κρατήστε τα δεδομένα μαζί στον ίδιο κατάλογο.

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
el: Τοποθέτηση των δεδομένων στην προσωρινή μνήμη ώστε να μην χρειάζεται συνεχώς να ξαναδιαβάζονται.

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
el: Διαμοιρασμός δεδομένων ώστε να μη χρειάζεται να τα ξαναδιαβάζει από το δίσκο κάθε εφαρμογή όταν φορτώνει.

note: (itstool) path: item/p
en: Consider caching all of the data in a single binary file that is properly aligned and can be mmaped.
el: Καλύτερα να αντιγράφετε όλα τα δεδομένα στην προσωρινή μνήμη σε ένα ενιαίο δυαδικό αρχείο που ευθυγραμμίζεται κατάλληλα και μπορεί να είναι mmaped.

note: (itstool) path: page/p
en: The trouble with disk seeks are compounded for reads, which is unfortunately what we are doing. Remember, reads are generally synchronous while writes are asynchronous. This only compounds the problem, serializing each read, and contributing to program latency.
el: Το πρόβλημα με την αναζητήσεις δίσκων είναι αρκετά σύνθετο όσο αναφορά την ανάγνωση, το όποιο είναι δυστυχώς αυτό που κάνουμε. Να θυμάστε, η ανάγνωση είναι γενικά σύγχρονή ενώ η εγγραφή είναι ασύγχρονη. Αυτό κάνει ποιο σύνθετο το πρόβλημα, διατάσσοντας σειριακά κάθε ανάγνωση, και συμβάλλοντας στη λανθάνουσα κατάσταση του προγράμματος.

note: (itstool) path: license/p
en: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting <link href="http://www.fsf.org">their Web site</link> or by writing to: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.
el: Χορηγείται άδεια για αντιγραφή, διανομή ή/και τροποποίηση του παρόντος εγγράφου υπό τους όρους της GNU Free Documentation License, έκδοση 1.1 ή οποιασδήποτε μεταγενέστερης έκδοσης που δημοσιεύεται από το Free Software Foundation χωρίς αμετάβλητα τμήματα, χωρίς κείμενο εξωφύλλου, και χωρίς κείμενο οπισθόφυλλου. Μπορείτε να λάβετε ένα αντίγραφο της GNU Free Documentation License από το Free Software Foundation με μία επίσκεψη στο <link href="http://www.fsf.org">δικτυακό τους τόπο</link> ή με γράμμα στο: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.

note: (itstool) path: license/p
en: Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any GNOME documentation, and those trademarks are made aware to the members of the GNOME Documentation Project, the names have been printed in caps or initial caps.
el: Πολλά από τα ονόματα που χρησιμοποιούνται από τις επιχειρήσεις για να διαφοροποιήσουν τα προϊόντα τους και τις υπηρεσίες τους εμφανίζονται ως εμπορικά σήματα. Όπου αυτά τα ονόματα εμφανίζονται σε οποιαδήποτε τεκμηρίωση του GNOME, και αυτά τα εμπορικά σήματα γίνονται γνωστά στα μέλη του έργου τεκμηρίωσης του GNOME, τα ονόματα θα τυπώνονται με κεφαλαία γράμματα ή γράμματα τίτλων.

note: (itstool) path: info/desc
en: Software can be optimized in many ways: for speed, program size, or memory use. This section contains guides and tutorials for optimizing your software.
el: Το λογισμικό μπορεί να βελτιστοποιηθεί από πολλές απόψεις: για την ταχύτητα, το μέγεθος του προγράμματος, ή τη χρήση μνήμης. Αυτό το τμήμα περιέχει οδηγούς και σεμινάρια για τη βελτιστοποίηση του λογισμικού σας.

note: (itstool) path: page/title
en: Optimization Guide
el: Οδηγός βελτιστοποίησης

note: (itstool) path: section/title
en: Introduction
el: Εισαγωγή

note: (itstool) path: section/p
en: This is a brief introduction to optimization, both the hows and the whys. Details of individual tools and techniques are left for later articles, but a collection of hints and tricks is provided.
el: Αυτή είναι μια σύντομη εισαγωγή στη βελτιστοποίηση, τόσο στο πώς όσο και στο γιατί. Οι λεπτομέρειες για ξεχωριστά εργαλεία και τεχνικές παραλείπονται για μελλοντικά άρθρα, αλλά παρέχεται μια συλλογή από υποδείξεις και κόλπα.

note: (itstool) path: section/p (itstool) path: page/p
en: This article describes how to use the <app>Massif</app> heap profiler with GNOME applications. We describe how to invoke, interpret, and act on the output of <app>Massif</app>. The <app>Swell Foop</app> game is used as an example.
el: Αυτό το άρθρο περιγράφει πώς χρησιμοποιείται ο σωρός κατατομών <app>Massif</app> με εφαρμογές του GNOME. Περιγράφουμε πώς να τον καλέσετε, να τον ερμηνεύσετε και πώς να ενεργήσετε βάσει των αποτελεσμάτων του <app>Massif</app>. Ως παράδειγμα χρησιμοποιούμε το παιχνίδι <app>Swell Foop</app>.

note: (itstool) path: section/title
en: Harmfulness
el: Βλαβερότητα

note: (itstool) path: page/title
en: What are we Optimizing?
el: Τι θα βελτιστοποιήσουμε;

note: (itstool) path: page/p
en: When we optimize for GNOME the first thing to remember is this: we are not trying to make the program better, we are trying to make the person using the computer happier.
el: Όταν βελτιστοποιούμε για το GNOME, το πρώτο πράγμα που θυμόμαστε είναι ότι δεν προσπαθούμε να κάνουμε ένα πρόγραμμα καλύτερο, προσπαθούμε να κάνουμε το χρήστη που χρησιμοποιεί τον υπολογιστή πιο ευχαριστημένο.

note: (itstool) path: page/p
en: Better programs make people happier, but there are some improvements that will make them a lot happier than others: Responsiveness, start-up time, easy to access commands and not having the computer go into swap the moment more than two programs are open.
el: Καλύτερα προγράμματα σημαίνει πιο ευχαριστημένοι χρήστες, αλλά υπάρχουν μερικές βελτιώσεις που θα τους κάνουν πιο ευχαριστημένους από άλλες: η σπιρτάδα της ανταπόκρισης, ο χρόνος εκκίνησης, η ευκολία στην πρόσβαση των εντολών και το να μην γίνεται πολύ αργός ο υπολογιστής όταν υπάρχουν ανοικτά περισσότερα από δύο προγράμματα.

note: (itstool) path: page/p
en: Traditional optimization tackles concepts like CPU use, code size, the number of mouse clicks and the memory use of the program. This second list has been chosen to correlate with the first list, however there is an important difference: The person using GNOME doesn't care about the second list, but they care a lot about the first list. When optimizing GNOME programs we will reduce CPU use, memory use and all those things, but these are the means to the end, not the final goal. We are optimizing for people.
el: Η παραδοσιακή βελτιστοποίηση ασχολείται με έννοιες όπως η χρήση του επεξεργαστή, το μέγεθος του κώδικα, ο αριθμός των κλικ του ποντικιού και η χρήση της μνήμης από το πρόγραμμα. Αυτή η δεύτερη λίστα έχει επιλεγεί για να συσχετίζεται με την πρώτη, ωστόσο υπάρχει μια σημαντική διαφορά: Αυτός που χρησιμοποιεί το GNOME δε νοιάζεται για τη δεύτερη λίστα, νοιάζεται όμως πολύ για την πρώτη. Όταν βελτιστοποιούμε προγράμματα του GNOME μειώνουμε τη χρήση του επεξεργαστή, της μνήμης και λοιπά, αλλά όλα αυτά είναι μέσα για να προχωρήσουμε, όχι για τον τελικό μας σκοπό. Εμείς βελτιστοποιούμε για τους ανθρώπους.

note: (itstool) path: section/title
en: Doing the Optimization
el: Εφαρμόζοντας τη βελτιστοποίηση

note: (itstool) path: section/p
en: The previous section omitted one important qualifier: To optimize something it has to be measurable. You can't measure happiness. However, you can measure start-up time so you can tell if you have improved it. Happiness will then, hopefully, follow.
el: Η προηγούμενη ενότητα παρέλειψε ένα σημαντικό παράγοντα: για να βελτιστοποιηθεί κάτι πρέπει να είναι μετρήσιμο. Δε μπορείτε να βελτιστοποιήσετε την ευχαρίστηση. Ωστόσο, μπορείτε να μετρήση το χρόνο εκκίνησης ώστε να μπορείτε να δείτε αν τον έχετε βελτιώσει. Ευελπιστούμε ότι η ευτυχία θα επέλθει.

note: (itstool) path: section/p
en: Optimization is the process of measurement, refinement and re-measurement. So the first thing you must do is find a way to measure what you are optimizing. Ideally this measurement is a single number, for example: the time taken to perform a task. This is your benchmark, it is the only way to tell if you are winning or losing. There is a big difference between a program that <em>should</em> be fast and a program that <em>is</em> fast.
el: Η βελτιστοποίηση είναι μια διαδικασία μέτρησης, βελτίωσης και μέτρησης ξανά. Οπότε το πρώτο πράγμα που πρέπει να κάνετε είναι να βρείτε έναν τρόπο για να μετρήσετε αυτό που βελτιστοποιείτε. Στην καλύτερη περίπτωση, αυτή η μέτρηση θα είναι ένας μοναδικός αριθμός, για παράδειγμα ο χρόνος που χρειάζεται για να ολοκληρωθεί μια εργασία. Αυτή η είναι η δοκιμή μέτρησής σας, και είναι ο μοναδικός τρόπος για να δείτε αν κερδίζετε ή αν χάνετε. Υπάρχει τεράστια διαφορά ανάμεσα σε ένα πρόγραμμα που <em>θα έπρεπε</em> να είναι γρήγορο και σε ένα που <em>είναι</em> γρήγορο.

note: (itstool) path: section/p
en: Once you have a basic benchmark you need to find out why your code is not doing as well as it should. It is tempting to do this by inspection: just looking at the code and trying to spot something that looks like it needs improvement. You will invariably be wrong. Using a profiler to get a detailed break-down of what your program really does is the only way to be sure.
el: Όταν θα έχετε μια βασική δοκιμή μέτρησης θα πρέπει να ανακαλύψετε γιατί ο κώδικάς σας δεν πάει τόσο καλά όσο θα έπρεπε. Είναι δελεαστικό να το κάνετε αυτό παρατηρώντας: να κοιτάτε τον κώδικα ψάχνοντας για κάτι που μοιάζει να θέλει βελτίωση. Χωρίς αμφιβολία, θα κάνετε λάθος. Η χρήση ενός βοηθητικού προγράμματος profiler το οποίο δίνει μια λεπτομερή ανατομία του τι κάνει πραγματικό το πρόγραμμά σας είναι ο μόνος τρόπος για να είστε βέβαιοι.

note: (itstool) path: section/p
en: Usually the problem is isolated to small sections of code. Pick the worst place and concentrate on that first. Once that is done, rerun the profiler and repeat. As you proceed the gains made at each step will get less and less, at some point you will have to decide that the results are good enough. If your efforts are only extracting 10% improvements then you are well past the point where you should have stopped.
el: Συνήθως το πρόβλημα εντοπίζεται σε μικρά τμήματα του κώδικα. Διαλέξτε το χειρότερο από αυτά και συγκεντρωθείτε πρώτα σ' αυτό. Όταν θα έχετε τελειώσει μ' αυτό, τρέξτε ξανά το profiler και επαναλάβετε τη διαδικασία. Καθώς θα προχωράτε, το κέρδος από κάθε βήμα θα μειώνεται, και σε κάποιο σημείο θα πρέπει να αποφασίσετε αν τα αποτελέσματα είναι αρκετά καλά. Αν η προσπάθειές σας έχουν ως αποτέλεσμα τη βελτίωση μόνο κατά 10% κάθε φορά, τότε έχετε περάσει το σημείο όπου μπορείτε πια να σταματήσετε.

note: (itstool) path: section/p
en: Don't forget the big picture. For example, rather than just trying to speed up a piece of code, ask yourself if it needs to be run at all. Could it be combined with another piece of code? Can the results of previous calculations be saved and reused? It won't even need to be optimized if it is in a place where the user is never going to notice it. Worse still, the code may already be optimized and is doing the heavy calculations now to avoid doing them later. Code does not run in isolation and neither does the optimization process.
el: Μη συγκεντρωθείτε στο δέντρο και χάσετε το δάσος. Για παράδειγμα, αντί να προσπαθείτε να επιταχύνετε ένα κομμάτι κώδικα, σκεφτείτε αν χρειάζεται καν να τρέχει. Μήπως μπορεί να συνδυαστεί με κάποιο άλλο κομμάτι; Μήπως μπορούν τα αποτελέσματα της προηγούμενης λειτουργίας του να αποθηκευτούν και να χρησιμοποιηθούν ξανά; Δε θα χρειαστεί καν να βελτιστοποιηθεί αν βρίσκεται σε ένα μέρος όπου ο χρήστης δε θα το προσέξει ποτέ. Ακόμα χειρότερα, ο κώδικας μπορεί να είναι ήδη βελτιστοποιημένος και να κάνει τώρα τους βαριούς του υπολογισμούς για να μην τους χρειαστεί αργότερα. Ούτε ο κώδικας τρέχει απομονωμένος, ούτε η βελτιστοποίηση.

note: (itstool) path: section/title
en: Hints
el: Υποδείξεις

note: (itstool) path: item/title
en: The Fundamentals
el: Τα βασικά

note: (itstool) path: item/p
en: Re-run your benchmark after every change you make to the code and keep a log of everything you change and how it affects the benchmark. This lets you undo mistakes and also helps you not to repeat mistakes.
el: Τρέξτε ξανά τις δοκιμαστικές σας μετρήσεις μετά από κάθε αλλαγή που κάνετε στον κώδικα και κρατήστε μια καταγραφή όλων των αλλαγών που κάνετε και πώς αυτές επηρεάζουν τις μετρήσεις. Αυτό σας βοηθά να αναιρείτε κάποια λάθη, όπως επίσης και να μην τα επαναλαμβάνετε.

note: (itstool) path: item/p
en: Make sure your code is correct and bug-free before optimizing it. Check that it remains correct and bug-free after optimization.
el: Βεβαιωθείτε ότι ο κώδικάς σας είναι σωστός και χωρίς σφάλματα προτού τον βελτιστοποιήσετε. Ελέγξτε ότι είναι σωστός και χωρίς σφάλματα και μετά τη βελτιστοποίηση.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
el: Βελτιστοποιήστε σε ψηλό επίπεδο πριν προχωρήσετε στις λεπτομέρειες.

note: (itstool) path: item/p
en: Use the right algorithm. The classic text-book example is using quick-sort instead of bubble-sort. There are many others, some save memory, some save CPU. Also, see what shortcuts you can make: you can do quicker than quick-sort if you are prepared to make some compromises.
el: Χρησιμοποιήστε το σωστό αλγόριθμο. Το κλασικό παράδειγμα είναι να χρησιμοποιήσετε το quick-sort αντί το bubble-sort. Υπάρχουν πολλά ακόμα, μερικά εξοικονομούν μνήμη, μερικά εξοικονομούν επεξεργαστή. Επίσης, δείτε τι συντόμια μπορείτε να ακολουθήσετε: μπορείτε να ταξινομήσετε και γρηγορότερα από το quick-sort αν μπορείτε να κάνετε μερικούς συμβιβασμούς.

note: (itstool) path: item/p
en: Optimization is a trade-off. Caching results speeds up calculations, but increases memory use. Saving data to disk saves memory, but costs time when it is loaded back from disk.
el: Η βελτιστοποίηση είναι και θέμα ισορροπίας. Η προσωρινή αποθήκευση αποτελεσμάτων επιταχύνει τους υπολογισμούς, αλλά κοστίζει σε μνήμη. Η αποθήκευση δεδομένων στο δίσκο εξοικονομεί τη μνήμη, αλλά κοστίζει σε χρόνο όταν θα πρέπει να διαβάσετε τις πληροφορίες από το δίσκο.

note: (itstool) path: item/p
en: Make sure you choose a wide variety of inputs to optimize against. If you don't it is easy to end up with a piece of code carefully optimized for one file and no others.
el: Βεβαιωθείτε ότι χρησιμοποιείτε μια πλατιά ποικιλία από εισόδους για τις οποίες θα βελτιστοποιήσετε. Αν δεν το κάνετε αυτό, εύκολα θα καταλήξετε σε ένα κομμάτι κώδικα προσεκτικά βελτιστοποιημένο για συγκεκριμένη λειτουργία αλλά όχι για άλλες.

note: (itstool) path: item/p
en: Avoid expensive operations: Multiple small disk reads. Using up lots of memory so disk swapping becomes necessary. Avoid anything that writes or reads from the hard disk unnecessarily. The network is slow too. Also avoid graphics operations that need a response from the X server.
el: Αποφύγετε τις σπάταλες λειτουργίες: Πολλαπλές μικρές αναγνώσεις από το δίσκο. Η χρήση πάρα πολλής μνήμης ώστε να χρειάζεται εικονική μνήμη στο δίσκο γίνεται απαραίτητη. Αποφύγετε ο,τιδήποτε γράφει ή διαβάζει από τον από τον σκληρό δίσκο άσκοπα. Το δίκτυο επίσης είναι αργό. Αποφύγετε επίσης λειτουργίες γραφικών οι οποίες χρειάζονται απάντηση από τον εξυπηρετητή X.

note: (itstool) path: item/title
en: Traps for the Unwary
el: Παγίδες για τους ανυποψίαστους

note: (itstool) path: item/p
en: Beware of side effects. There can often be strange interactions between different sections of code, a speed-up in one part can slow another part down.
el: Προσέχετε τις παρενέργειες. Συχνά μπορεί να υπάρχουν περίεργες αλληλεπιδράσεις μεταξύ διαφορετικών κομματιών κώδικα, και η επιτάχυνση ενός κομματιού μπορεί να επιβραδύνει ένα άλλο.

note: (itstool) path: item/p
en: When timing code, even on a quiet system, events outside the program add noise to the timing results. Average over multiple runs. If the code is very short, timer resolution is also a problem. In this case measure the time the computer takes to run the code 100 or 1000 times. If the times you are recording are longer than a few seconds, you should be OK.
el: Όταν χρονομετράτε τον κώδικα, ακόμα και σε ένα ήσυχο σύστημα, γεγονότα εκτός από το πρόγραμμα προσθέτουν θόρυβο στα αποτελέσματα των μετρήσεων. Τρέξτε πολλές φορές το πρόγραμμα και πάρτε το μέσο όρο. Αν ο κώδικας είναι πολύ σύντομος, η ανάλυση του χρονομέτρου είναι επίσης προβληματική. Σε τέτοια περίπτωση, χρονομετρήστε την εκτέλεση του κώδικα για 100 ή 1000 φορές. Αν οι φορές που χρονομετράτε διαρκούν περισσότερο από μερικά δευτερόλεπτα, τότε θα πρέπει να είστε εντάξει.

note: (itstool) path: item/p
en: It is very easy to be misled by the profiler. There are stories of people optimizing the operating system idle-loop because that is where it spent all its time! Don't optimize code that does nothing the user cares about.
el: Είναι πάρα πολύ εύκολο να σας παραπλανήσει ο profiler. Υπάρχουν περιπτώσεις ανθρώπων που βελτιστοποιούσαν τον βρόχο παύσης του λειτουργικού συστήματος επειδή εκεί τους έδειχνε ο profiler ότι ρο σύστημα σπαταλούσε τον περισσότερο χρόνο του! Μη βελτιστοποιείτε κώδικα που δεν κάνει τίποτα χρήσιμο για το χρήστη.

note: (itstool) path: item/p
en: Remember the resources on the X server. Your program's memory usage doesn't include the pixmaps that are stored in the X server's process, but they are still using up memory. Use xrestop to see what resources your program is using.
el: Να θυμάστε τους πόρους του εξυπηρετητή X. Η χρήση μνήμης του προγράμματός σας δεν περιλαμβάνει τα pixmap που αποθηκεύονται στις διεργασίες του εξυπηρετητή X, αλλά και πάλι χρησιμοποιούν μνήμη. Χρησιμοποιήστε το xrestop για να δείτε ποιοι πόροι χρησιμοποιούνται από το πρόγραμμά σας.

note: (itstool) path: item/title
en: Low Level Hints
el: Υποδείξεις χαμηλού επιπέδου

note: (itstool) path: item/p
en: When optimizing memory use, be wary of the difference between peak usage and average memory usage. Some memory is almost always allocated, this is usually bad. Some is only briefly allocated, this may be quite acceptable. Tools like massif use the concept of space-time, the product of memory used and the duration it was allocated for, instead.
el: Όταν βελτιστοποιείτε τη χρήση της μνήμης, προσέξτε τη διαφορά ανάμεσα στη μέγιστη χρήση και στη μέση χρήση. Σχεδόν πάντα κατανέμεται κάποια ποσότητα μνήμης για χρήση από το πρόγραμμα, το οποίο είναι συνήθως κακό. Κάποια μνήμη είναι μόνο κατανεμημένη για λίγο, και αυτό μπορεί να είναι αποδεκτό. Εργαλεία όπως το massif χρησιμοποιούν την έννοια του χωροχρόνου, το γινόμενο της ποσότητας της μνήμης που χρησιμοποιείται και της διάρκειας κατά την οποία ήταν κατανεμημένη.

note: (itstool) path: item/p
en: Time simplified bits of code that do only the things you know are essential, this gives an absolute lower limit on the time your code will take. For example, when optimizing a loop time the empty loop. If that is still too long no amount of micro-optimization will help and you will have to change your design. Make sure the compiler doesn't optimize away your empty loop.
el: Τα απλοποιημένα κομμάτια κώδικα που κάνουν μόνο πράγματα που ξέρετε είναι ουσιώδη, γιατί σας δίνουν το απόλυτα χαμηλότερο όριο για το χρόνο που χρειάζεται ο κώδικάς σας. Για παράδειγμα, όταν βελτιστοποιείτε ένα βρόχο, χρονομετρήστε τον ενώ είναι άδειος. Αν αυτός ο χρόνος είναι πολύ μεγάλος, τότε δε θα σας βοηθήσει καθόλου η μικροβελτιστοποίηση, και θα πρέπει να αλλάξετε το σχεδιασμό σας. Βεβαιωθείτε ότι ο μεταγλωττιστής δε βελτιστοποιεί τον άδειο βρόχο.

note: (itstool) path: item/p
en: Move code out from inside loops. A slightly more complicated piece of code that is executed once is far quicker than a simple piece of code executed a thousand times. Avoid calling slow code often.
el: Αφαιρέστε κώδικα από εσωτερικούς βρόχους. Ένα λίγο πιο πολύπλοκο κομμάτι κώδικα που εκτελείται μια φορά είναι πολύ γρηγορότερο από ένα απλούστερο κομμάτι κώδικα που εκτελείται χίλιες φορές. Αποφύγετε να καλείτε συχνά αργό κώδικα.

note: (itstool) path: item/p
en: Give the compiler as many hints as possible. Use the const keyword. Use <code>G_INLINE_FUNC</code> for short, frequently called, functions. Look up <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> and the other glib miscellaneous macros. Use the macros instead of gcc-specific keywords to ensure portability.
el: Δώστε στον μεταγλωττιστή όσες περισσότερες υποδείξεις μπορείτε. Χρησιμοποιήστε τη λέξη κλειδί const. Χρησιμοποιήστε τον <code>G_INLINE_FUNC</code> για συντομία, συναρτήσεων που καλούνται συχνά. Ψάξτε για τις μακροεντολές <code>G_GNUC_PURE</code>, <code>G_LIKELY</code>, και διάφορες άλλες της glib. Χρησιμοποιήστε τις μακροεντολές αντί για ειδικές λέξεις κλειδιά του gcc, για να εξασφαλίσετε τη φορητότητα.

note: (itstool) path: item/p
en: Don't use assembly language. It is not portable and, while it may be fast on one processor, it is not even guaranteed to be fast on every processor that supports that architecture (e.g. Athlon vs. Pentium 4).
el: Μη χρησιμοποιείτε τη γλώσσα assembly. Δεν είναι φορητή και ενώ μπορεί να είναι γρήγορη σε έναν επεξεργαστή, δεν είναι εγγυημένο ότι θα είναι γρήγορη και σε οποιοδήποτε άλλο επεξεργαστή που υποστηρίζει αυτήν την αρχιτεκτονική (π.χ. Athlon vs Pentium 4).

note: (itstool) path: item/p
en: Don't rewrite an existing library routine unless you are sure it is unnecessarily slow. Many CPU-intensive library routines have already been optimized. Conversely, some library routines are slow, especially ones that make system calls to the operating system.
el: Μη ξαναγράψετε μια υφιστάμενη βιβλιοθήκη εκτός και αν είστε βέβαιοι ότι είναι αδικαιολόγητα αργή. Πολλές βιβλιοθήκες που καταπονούν τον επεξεργαστή είναι ήδη βελτιστοποιημένες. Αντίστοιχα, μερικές ρουτίνες βιβλιοθηκών είναι αργές, ειδικά μερικές που κάνουν πολλές κλήσεις συστήματος στο λειτουργικό σύστημα.

note: (itstool) path: item/p
en: Minimize the number of libraries you link to. The fewer libraries to link in, the faster the program starts. This is a difficult thing to do with GNOME.
el: Ελαχιστοποιήστε τον αριθμό των βιβλιοθηκών με τις οποίες συνδέεστε. Με όσο λιγότερες βιβλιοθήκες συνδέεται ένα πρόγραμμα, τόσο γρηγορότερα ξεκινά. Αυτό είναι κάτι δύσκολο να γίνει στο GNOME.

note: (itstool) path: item/title
en: High Level Tricks
el: Κόλπα υψηλού επιπέδου

note: (itstool) path: item/p
en: Take advantage of concurrency. This doesn't just mean using multiple processors, it also means taking advantage of the time the user spends thinking about what they are going to do next to perform some calculations in anticipation. Do calculations while waiting for data to be loaded off disk. Take advantage of multiple resources, use them all at once.
el: Εκμεταλλευτείτε το συγχρονισμό. Αυτό δε σημαίνει μόνο να χρησιμοποιείτε πολλαπλούς επεξεργαστές, αλλά και να εκμεταλλεύεστε το χρόνο που ο χρήστης σπαταλά να σκέφτεται τι θα κάνει στη συνέχεια, για να κάνετε μερικούς υπολογισμούς που χρειάζεστε. Κάντε υπολογισμούς ενώ περιμένετε για πληροφορίες να φορτωθούν από το δίσκο. Εκμεταλλευτείτε πολλαπλούς πόρους, χρησιμοποιώντας τους ταυτόχρονα.

note: (itstool) path: item/p
en: Cheat. The user only has to think that the computer is fast, it doesn't matter whether it actually is or not. It is the time between the command and the answer that is important, it doesn't matter if the response is pre-calculated, cached, or will in fact be worked out later at a more convenient time, as long as the user gets what they expect.
el: Ξεγελάστε. Ο χρήστης χρειάζεται μόνο να νομίζει ότι ο υπολογιστής είναι γρήγορος, άσχετα αν πραγματικά είναι. Σημασία έχει ο χρόνος μεταξύ της εντολής και της απάντησης, και όχι αν η απάντηση υπολογίστηκε από πριν, ή ήταν προσωρινά αποθηκευμένη, ή ακόμα και αν θα υπολογιστεί αργότερα σε κάποιο πιο βολικό χρόνο, φτάνει ο χρήστης να πάρει αυτό που περιμένει.

note: (itstool) path: item/p
en: Do things in the idle loop. It is easier to program than using full multi-threading but still gets things done out of the users eye. Be careful though, if you spend too long in the idle loop your program will become sluggish. So regularly give control back to the main loop.
el: Κάντε πράγματα στον ανενεργό βρόχο. Είναι ευκολότερο στον προγραμματισμό από τη χρήση πολυνηματικότητας, αλλά και πάλι επιτυγχάνει να κάνει πράγματα χωρίς να το αντιλαμβάνεται ο χρήστης. Να είστε όμως προσεκτικοί, γιατί αν σπαταλάτε πολύ χρόνο στον ανενεργό βρόχο τότε το πρόγραμμά σας γίνεται αργό. Οπότε να δίνεται τακτικά τον έλεγχο στον κύριο βρόχο.

note: (itstool) path: item/p
en: If all else fails, tell the user that the code is going to be slow and put up a progress bar. They won't be as happy as if you had just presented the results, but they will at least know the program hasn't crashed and they can go get a cup of coffee.
el: Αν όλα τα υπόλοιπα αποτύχουν, πείτε στο χρήστη ότι ο κώδικας είναι αργός και βάλτε μια μπάρα προόδου. Δε θα είναι τόσο ευχαριστημένος όσο θα ήταν αν του δίνατε άμεσα αποτελέσματα, αλλά τουλάχιστον θα ξέρουν ότι το πρόγραμμα δεν κόλλησε και ότι μπορούν να σηκωθούν και να φτιάξουν ένα καφεδάκι.

note: (itstool) path: page/title
en: Using <app>Massif</app> for Profiling Memory Use in GNOME Software
el: Χρησιμοποιήστε το <app>Massif</app> για την χρήσης της μνήμης κατατομής σε εφαρμογές του GNOME

note: (itstool) path: section/p
en: <app>Massif</app> is a member of the <link href="http://valgrind.org/">valgrind</link> suite of memory-profiling tools. Its purpose is to give a detailed view of dynamic memory usage during the lifetime of the program. Specifically it records the memory use of the heap and the stack.
el: Η <app>Massif</app> είναι μέλος της σειράς <link href="http://valgrind.org/">valgrind</link> για εργαλεία κατατομής μνήμης. Ο σκοπός του είναι να δίνει μια λεπτομερή προβολή της δυναμικής χρήσης της μνήμης κατά τη διάρκεια του χρόνου ζωής ενός προγράμματος. Συγκεκριμένα, καταγράφει τη χρήση της μνήμης από το σωρό και τη στοίβα.

note: (itstool) path: section/p
en: The heap is the region of memory which is allocated with functions like malloc. It grows on demand and is usually the largest region of memory in a program. The stack is where all the local data for functions is stored. This includes the "automatic" variables in C and the return address for subroutines. The stack is typically a lot smaller and a lot more active than the heap. We won't consider the stack explicitly since <app>Massif</app> treats it as though it were just another part of the heap. <app>Massif</app> also gives information about how much memory is used to manage the heap.
el: Ο σωρός είναι η περιοχή στη μνήμη η οποία κατανέμεται με συναρτήσεις όπως η malloc. Μεγαλώνει κατά απαίτηση και είναι συνήθως η μεγαλύτερη περιοχή της μνήμης σε ένα πρόγραμμα. Η στοίβα είναι εκεί όπου αποθηκεύονται όλα τα τοπικά δεδομένα για τις συναρτήσεις. Αυτό συμπεριλαμβάνει τις "αυτόματες" μεταβλητές στη C και τη διεύθυνση επιστροφής για τις υπορουτίνες. Η στοίβα είναι τυπικά πολύ μικρότερη και πολύ πιο ενεργή από το σωρό. Δε θα ασχοληθούμε ειδικά με τη στοίβα μια που το <app>Massif</app> την αντιμετωπίζει σαν να ήταν μέρος του σωρού. Το <app>Massif</app> παρέχει επίσης πληροφορίες για την ποσότητα της μνήμης που χρησιμοποιείται για τη διαχείριση του σωρού.

note: (itstool) path: section/p
en: <app>Massif</app> produces two output files: a graphical overview in a postscript file and a detailed breakdown in a text file.
el: Η <app>Massif</app> παράγει δύο αρχεία εξόδου: μια γραφική επισκόπηση σε ένα αρχείο postscript και μια λεπτομερή ανάλυση σε ένα αρχείο κειμένου.

note: (itstool) path: section/title
en: Using <app>Massif</app> with GNOME
el: Χρήση της <app>Massif</app> με το GNOME

note: (itstool) path: section/p
en: <app>Massif</app> has very few options and for many programs does not need them. However for GNOME applications, where memory allocation might be buried deep in either glib or GTK, the number of levels down the call-stack Massif descends needs to be increased. This is achieved using the --depth parameter. By default this is 3; increasing it to 5 will guarantee the call-stack reaches down to your code. One or two more levels may also be desirable to provide your code with some context. Since the level of detail becomes quickly overwhelming it is best to start with the smaller depth parameter and only increase it when it becomes apparent that it isn't sufficient.
el: Η <app>Massif</app> έχει πολύ λίγες επιλογές και για τα περισσότερα προγράμματα δεν τις χρειάζεστε. Εντούτοις για της εφαρμογές του GNOME, όπου η κατανομή μνήμης μπορεί να θαφτεί βαθιά στο glib ή στο GTK, ο αριθμός επιπέδων κάτω από την στοίβα κλήσεων που η Massif κατεβαίνει θα πρέπει να αυξηθεί. Αυτό είναι γίνεται χρησιμοποιώντας την παράμετρο --depth. Εξ ορισμού αυτό είναι ίσο με 3· αυξάνοντας το σε 5 εγγυάται ότι η στοίβα κλήσεων θα φθάσει στον κώδικά σας. Ένα ή δύο περισσότερα επίπεδα μπορούν επίσης να είναι επιθυμητά και να παρέχουν στον κώδικά σας κάποιο πλαίσιο εφαρμογής. Δεδομένου ότι το επίπεδο λεπτομέρειας γίνεται γρήγορα συντριπτικό είναι καλύτερο να αρχίσει με μικρότερη παράμετρο βάθους και να το αυξήστε μόνο όταν γίνεται προφανές ότι αυτό δεν είναι ικανοποιητικό.

note: (itstool) path: section/p
en: It is also useful to tell <app>Massif</app> which functions allocate memory in glib. It removes an unnecessary layer of function calls from the reports and gives you a clearer idea of what code is allocating memory. The allocating functions in glib are g_malloc, g_malloc0, g_realloc, g_try_malloc, and g_mem_chunk_alloc. You use the --alloc-fn option to tell Massif about them.
el: Είναι επίσης χρήσιμο να πείτε στο <app>Massif</app> ποιες συναρτήσεις δεσμεύουν χώρο στη μνήμη μέσω του glib. Αφαιρεί ένα περιττό στρώμα κλήσεων συναρτήσεων από τις αναφορές και σας δίνει μια σαφέστερη ιδέα ποιος κώδικας δεσμεύει χώρο στην μνήμη. Οι συναρτήσεις δέσμευσης χώρου μνήμης μέσω του glib είναι οι g_malloc, g_malloc0, g_realloc, g_try_malloc, και g_mem_chunk_alloc. Χρησιμοποιήστε την επιλογή --alloc-fn για να ενημερώστε το Masiff για αυτές.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
el: Η γραμμή-εντολών σας πρέπει επομένως να μοιάζει κάπως σαν:

note: (itstool) path: section/p
en: <app>Swell Foop</app> is the program we will be using as an example. Be warned that, since valgrind emulates the CPU, it will run <em>very</em> slowly. You will also need a lot of memory.
el: Το <app>Swell Foop</app> είναι το πρόγραμμα που θα χρησιμοποιούμε σαν παράδειγμα. Σας προειδοποιούμε ότι, από την στιγμή που ο valgrind θα εξομοιώνει την ΚΜΕ, θα λειτουργεί <em>πολύ</em> αργά. Θα χρειαστείτε επίσης πολλή μνήμη.

note: (itstool) path: section/title
en: Interpreting the Results
el: Ερμηνεία των αποτελεσμάτων

note: (itstool) path: section/p
en: The graphical output of <app>Massif</app> is largely self explanatory. Each band represents the memory allocated by one function over time. Once you identify which bands are using the most memory, usually the big thick ones at the top you will have to consult the text file for the details.
el: Η γραφική έξοδος δεδομένων του <app>Massif</app> είναι κατά ένα μεγάλο μέρος αυτοεπεξηγηματικός. Κάθε ζώνη αντιπροσωπεύει τη μνήμη που διατίθεται από μια λειτουργία σε σχέση με τον χρόνο. Μόλις προσδιορίσετε ποιες ζώνες χρησιμοποιούν την περισσότερη μνήμη, συνήθως οι μεγάλες παχιές ζώνες στην κορυφή, θα πρέπει να συμβουλευθείτε το αντίστοιχο αρχείο κειμένου για περισσότερες λεπτομέρειες.

note: (itstool) path: section/p
en: The text file is arranged as a hierarchy of sections, at the top is a list of the worst memory users arranged in order of decreasing spacetime. Below this are further sections, each breaking the results down into finer detail as you proceed down the call-stack. To illustrate this we will use the output of the command above.
el: Τα αρχεία κειμένων τακτοποιούνται ιεραρχικά βάση των τμημάτων, στην κορυφή είναι μία λίστα των χειρότερων χρηστών μνήμης που τακτοποιούνται κατά σειρά βάση την μείωση του χωροχρόνου. Κάτω από αυτά είναι και άλλα τμήματα, κάθε ένα διαιρεί τα αποτελέσματα σε μικρότερες λεπτομέρειες καθώς προχωράτε προς τη στοίβα κλήσεων. Για να επεξηγήσουμε αυτό θα χρησιμοποιήσουμε την έξοδος δεδομένων της εντολής παραπάνω.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the unoptimized version of the <app>Swell Foop</app> program.
el: Έξοδος δεδομένων του <app>Massif</app> για την μη-βελτιστοποιημένη έκδοση του προγράμματος <app>Swell Foop</app>.

note: (itstool) path: section/p
en: The image above shows a typical postscript output from <app>Massif</app>. This is the result you would get from playing a single game of <app>Swell Foop</app> (version 2.8.0) and then quitting. The postscript file will have a name like <file>massif.12345.ps</file> and the text file will be called <file>massif.12345.txt</file>. The number in the middle is the process ID of the program that was examined. If you actually try this example you will find two versions of each file, with slightly different numbers, this is because <app>Swell Foop</app> starts a second process and <app>Massif</app> follows that too. We will ignore this second process, it consumes very little memory.
el: Η εικόνα παραπάνω παρουσιάζει μία χαρακτηριστική έξοδο δεδομένων σε μορφή postscript από το <app>Massif</app>. Αυτό είναι το αποτέλεσμα που θα παίρνατε παίζοντας μία πίστα από το παιχνίδι <app>Swell Foop</app> (έκδοση 2.8.0) και έπειτα το κλείνατε. Το αρχείο postscript θα έχει ένα όνομα όπως <file>massif.12345.ps</file> και το αρχείο κειμένων θα ονομάζεται <file>massif.12345.txt</file>. Ο αριθμός στη μέση είναι η ταυτότητα διαδικασίας του προγράμματος που εξετάστηκε. Εάν δοκιμάσετε πραγματικά αυτό το παράδειγμα θα βρείτε δύο εκδόσεις κάθε αρχείου, με ελαφρά διαφορετικούς νούμερα, αυτό συμβαίνει γιατί το <app>Swell Foop</app> ξεκινά μια δεύτερη διαδικασία και το <app>Massif</app> ακολουθεί και αυτή επίσης. Θα αγνοήσουμε αυτήν την δεύτερη διαδικασία, μια που καταναλώνει πολύ λίγη μνήμη.

note: (itstool) path: section/p
en: At the top of the graph we see a large yellow band labelled gdk_pixbuf_new. This seems like an ideal candidate for optimization, but we will need to use the text file to find out what is calling gdk_pixbuf_new. The top of the text file will look something like this:
el: Στην κορυφή της γραφικής παράστασης βλέπουμε μια μεγάλη κίτρινη ζώνη με τίτλο gdk_pixbuf_new. Αυτό φαίνεται ως ένας ιδανικός υποψήφιος για βελτιστοποίηση, αλλά θα πρέπει να χρησιμοποιήσουμε το αρχείο κειμένων για να ανακαλύψουμε τι καλεί το gdk_pixbuf_new. Στην κορυφή του αρχείου κειμένων θα εμφανίζεται κάτι σαν το επόμενο:

note: (itstool) path: section/code
en: 
    Command: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 90.4% of measured spacetime
    
    Called from:
      28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
        6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
el: 
    Εντολή: ./swell-foop
    
    == 0 ===========================
    Συναρτήσεις κατανομής σωρών που καταμετρήθηκαν ως το 90.4% από το μετρήσιμο χωρόχρoνο
    
    Καλείται από:
      28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
        6.1% : 0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
    
        5.9% : 0x510B3C: (μέσα στο /usr/lib/libfreetype.so.6.3.7)
    
        3.5% : 0x2A4A6B: __gconv_open (στο /lib/tls/libc-2.3.3.so)

note: (itstool) path: section/p
en: The line with the '=' signs indicates how far down the stack trace we are, in this case we are at the top. After this it lists the heaviest users of memory in order of decreasing spacetime. Spacetime is the product of the amount of memory used and how long it was used for. It corresponds to the area of the bands in the graph. This part of the file tells us what we already know: most of the spacetime is dedicated to gdk_pixbuf_new. To find out what called gdk_pixbuf_new we need to search further down the text file:
el: Η γραμμή με το σύμβολο του '=' δείχνει πόσο βαθιά κάτω είμαστε στο ίχνος στοίβας, σε αυτήν την περίπτωση είμαστε στην κορυφή. Μετά από αυτό απαριθμεί τους βαρύτερους χρήστες της μνήμης έτσι ώστε να μειωθεί ο χωρόχρονος. Ο χωρόχρονος είναι το λόγος του ποσού της μνήμης που χρησιμοποιείται και του χρόνου χρησιμοποίησης του. Αντιστοιχεί στον περιοχή των ζωνών στη γραφική παράσταση. Αυτό το μέρος του αρχείου μας λέει αυτό που ξέρουμε ήδη: το μεγαλύτερο μέρος του χωροχρόνου αφιερώνεται στο gdk_pixbuf_new. Για να ανακαλύψουν τι κάλεσε το gdk_pixbuf_new πρέπει να ψάξουμε περαιτέρω μέσα στο αρχείο κειμένου:

note: (itstool) path: section/code
en: 
    == 4 ===========================
    Context accounted for 28.8% of measured spacetime
      0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
      0x3A998998: (within /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)
      0x6C2760: (within /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
      0x6C285E: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
    Called from:
      27.8% : 0x804C1A3: load_scenario (swell-foop.c:463)
    
        0.9% : 0x3E8095E: (within /usr/lib/libgnomeui-2.so.0.792.0)
    
      and 1 other insignificant place
el: 
    == 4 ===========================
    Πλαίσιο καταμέτρησης για το 28.8% του υπολογίσιμου χωροχρόνου
      0x6BF83A: gdk_pixbuf_new (στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
      0x3A998998: (μέσα στο /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)
      0x6C2760: (μέσα στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
      0x6C285E: gdk_pixbuf_new_from_file (στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
    Καλείται από:
      27.8% : 0x804C1A3: load_scenario (swell-foop.c:463)
    
        0.9% : 0x3E8095E: (μέσα στο /usr/lib/libgnomeui-2.so.0.792.0)
    
      και 1 άλλη ασήμαντη θέση

note: (itstool) path: section/p
en: The first line tells us we are now four levels deep into the stack. Below it is a listing of the function calls that leads from here to gdk_pixbuf_new. Finally there is a list of functions that are at the next level down and call these functions. There are, of course, also entries for levels 1, 2, and 3, but this is the first level to reach right down through the GDK code to the <app>Swell Foop</app> code. From this listing, we can see instantly that the problem code is load_scenario.
el: Η πρώτη γραμμή μας λέει ότι είμαστε τώρα τέσσερα επίπεδα βαθιά μέσα στη στοίβα. Από κάτω βρίσκεται η λίστα των κλήσεων λειτουργίας που μας οδηγεί από εδώ στο gdk_pixbuf_new. Τελικά υπάρχει μία λίστα λειτουργιών που είναι στο επόμενο κάτω επίπεδο και καλούν αυτές τις λειτουργίες. Υπάρχουν, φυσικά, καταχωρίσεις για τα επίπεδα 1, 2, και 3, αλλά αυτό είναι το πρώτο επίπεδο που φθάνει ακριβώς στον κώδικα GDK του <app>Swell Foop</app>. Από αυτήν την λίστα, μπορούμε να δούμε αμέσως ότι ο προβληματικός κώδικας είναι ο load_scenario.

note: (itstool) path: section/p
en: Now that we know what part of our code is using all the spacetime we can look at it and find out why. It turns out that the load_scenario is loading a pixbuf from file and then never freeing that memory. Having identified the problem code, we can start to fix it.
el: Τώρα που ξέρουμε ποιο μέρος του κώδικά μας χρησιμοποιεί όλο χωρόχρονο μπορούμε να εξετάσουμε και να ανακαλύψουμε το γιατί. Ως αποτέλεσμα βλέπουμε ότι το load_scenario φορτώνει την pixbuf από ένα αρχείο και έπειτα δεν απελευθερώνει ποτέ την μνήμη. Αφού προσδιορίσαμε τον προβληματικό κώδικα, μπορούμε να αρχίσουμε να τον διορθώνουμε.

note: (itstool) path: section/title
en: Acting on the Results
el: Ενέργειες πάνω στα αποτελέσματα

note: (itstool) path: section/p
en: Reducing spacetime consumption is good, but there are two ways of reducing it and they are not equal. You can either reduce the amount of memory allocated, or reduce the amount of time it is allocated for. Consider for a moment a model system with only two processes running. Both processes use up almost all the physical RAM and if they overlap at all then the system will swap and everything will slow down. Obviously if we reduce the memory usage of each process by a factor of two then they can peacefully coexist without the need for swapping. If instead we reduce the time the memory is allocated by a factor of two then the two programs can coexist, but only as long as their periods of high memory use don't overlap. So it is better to reduce the amount of memory allocated.
el: Μειώνοντας την κατανάλωση του χωροχρόνου είναι κάτι καλό, αλλά υπάρχουν δύο τρόποι για την μείωση του που δεν είναι ισότιμες. Μπορείτε είτε να μειώσετε το ποσό μνήμης που διατίθεται, ή μειώστε το χρονικό διάστημα που του διατίθεται. Εξετάστε για μια στιγμή ένα πρότυπο σύστημα με μόνο δύο διαδικασίες ενεργές. Και οι δύο διαδικασίες καταναλώνουν σχεδόν όλη την φυσική μνήμη RAM και εάν κάποια στιγμή επικαλύψει η μία την άλλη το σύστημα θα κάνει αντιμετάθεση και όλα θα επιβραδύνουν. Προφανώς εάν μειώνουμε τη χρήση μνήμης σε κάθε διαδικασία με παράγοντα του δύο θα μπορούν ειρηνικά να συνυπάρξουν χωρίς την ανάγκη για αντιμετάθεση. Εάν αντ' αυτού μειώσουμε το χρόνο που διατίθεται η μνήμη με παράγοντα του δύο τότε τα δύο προγράμματα μπορούν να συνυπάρξουν, αλλά μόνο εφ' όσον οι περίοδοι υψηλής χρήσης της μνήμης τους δεν επικαλύπτονται. Έτσι είναι καλύτερο να μειωθεί το ποσό μνήμης που διατίθεται.

note: (itstool) path: section/p
en: Unfortunately, the choice of optimization is also constrained by the needs of the program. The size of the pixbuf data in <app>Swell Foop</app> is determined by the size of the game's graphics and cannot be easily reduced. However, the amount of time it spends loaded into memory can be drastically reduced. The image below shows the <app>Massif</app> analysis of <app>Swell Foop</app> after being altered to dispose of the pixbufs once the images have been loaded into the X server.
el: Δυστυχώς, η επιλογή της βελτιστοποίησης περιορίζεται επίσης από τις ανάγκες του προγράμματος. Το μέγεθος των δεδομένων του pixbuf στο <app>Swell Foop</app> καθορίζεται από το μέγεθος των γραφικών του παιχνιδιού και δεν μπορεί να μειωθεί εύκολα. Εντούτοις, το χρονικό διάστημα που ξοδεύει κατά την φόρτωση του στη μνήμη μπορεί να μειωθεί δραστικά. Η παραπάνω εικόνα παρουσιάζει την ανάλυση του <app>Massif</app> για το <app>Swell Foop</app> μετά από την αλλαγή του για να απορρίπτει τα pixbufs μόλις φορτωθούν οι εικόνες στον διακομιστή X.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the optimized <app>Swell Foop</app> program.
el: Έξοδος του <app>Massif</app> για την βελτιστοποιημένο πρόγραμμα <app>Swell Foop</app>.

note: (itstool) path: section/p
en: The spacetime use of gdk_pixbuf_new is now a thin band that only spikes briefly (it is now the sixteenth band down and shaded magenta). As a bonus, the peak memory use has dropped by 200 kB since the spike occurs before other memory is allocated. If two processes like this were run together the chances of the peak memory usage coinciding, and hence the risk of swapping, would be quite low.
el: Η χρήση του χωροχρόνου από το gdk_pixbuf_new είναι τώρα μια λεπτή ζώνη που έχει σύντομες αναλαμπές (είναι τώρα η δέκατη έκτη ζώνη και βαθυπόρφυρη απόχρωση). Σαν πρόσθετο χαρακτηριστικό, η μέγιστη χρήση μνήμης έχει ελαττωθεί κατά 200 kB δεδομένου ότι η αιχμή εμφανίζεται πριν δεσμευτεί η μνήμη. Εάν δύο διαδικασίες όπως αυτή εκτελούνται από κοινού οι πιθανότητες της μέγιστης χρήσης μνήμης συμπίπτουν, και ως εκ τούτου ο κίνδυνος αντιμετάθεσης, θα είναι αρκετά χαμηλός.

note: (itstool) path: section/p
en: Can we do better ? A quick examination of <app>Massif</app>'s text output reveals: g_strdup to be the new major offender.
el: Μπορούμε να το κάνουμε καλύτερα; Μια γρήγορη εξέταση της εξόδου κειμένου του <app>Massif</app> αποκαλύπτει ότι: το g_strdup είναι ο νέος σημαντικός ένοχος.

note: (itstool) path: section/code
en: 
    Command: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 87.6% of measured spacetime
    
    Called from:
        7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)
    
        6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
el: 
    Εντολή: ./swell-foop
    
    == 0 ===========================
    Συναρτήσεις κατανομής σωρών που καταμετρήθηκαν ως το 87.6% από το μετρήσιμο χωρόχρονο
    
    Καλείται από:
        7.7% : 0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
    
        7.6% : 0x43BC9F: (μέσα στο /usr/lib/libgdk-x11-2.0.so.0.400.9)
    
        6.9% : 0x510B3C: (μέσα στο /usr/lib/libfreetype.so.6.3.7)
    
        5.2% : 0x2A4A6B: __gconv_open (στο /lib/tls/libc-2.3.3.so)

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
el: Εάν το εξετάσουμε ποιο ενδελεχώς θα δούμε ότι καλείται από πολλές, πολλές, διαφορετικές θέσεις.

note: (itstool) path: section/code
en: 
    == 1 ===========================
    Context accounted for  7.7% of measured spacetime
      0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
    Called from:
        1.8% : 0x8BF606: gtk_icon_source_copy (in /usr/lib/libgtk-x11-2.0.so.0.400.9)
    
        1.1% : 0x67AF6B: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.400.6)
    
        0.9% : 0x91FCFC: (within /usr/lib/libgtk-x11-2.0.so.0.400.9)
    
        0.8% : 0x57EEBF: g_quark_from_string (in /usr/lib/libglib-2.0.so.0.400.6)
    
      and 155 other insignificant places
el: 
    == 1 ===========================
    Πλαίσιο καταμέτρησης για το 7.7% του υπολογίσιμου χωροχρόνου
      0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
    
    Κλήθηκε από:
        1.8% : 0x8BF606: gtk_icon_source_copy (στο /usr/lib/libgtk-x11-2.0.so.0.400.9)
    
        1.1% : 0x67AF6B: g_param_spec_internal (στο /usr/lib/libgobject-2.0.so.0.400.6)
    
        0.9% : 0x91FCFC: (μέσα στο /usr/lib/libgtk-x11-2.0.so.0.400.9)
    
        0.8% : 0x57EEBF: g_quark_from_string (στο /usr/lib/libglib-2.0.so.0.400.6)
    
      και 155 άλλες ασήμαντες θέσεις

note: (itstool) path: section/p
en: We now face diminishing returns for our optimization efforts. The graph hints at another possible approach: Both the "other" and "heap admin" bands are quite large. This tells us that there are a lot of small allocations being made from a variety of places. Eliminating these will be difficult, but if they can be grouped then the individual allocations can be larger and the "heap admin" overhead can be reduced.
el: Τώρα αντιμετωπίζουμε την ελάττωση της ανταμοιβή μας για τις προσπάθειες βελτιστοποίησής. Οι συμβουλές γραφικών παραστάσεων είναι μια άλλη πιθανή προσέγγιση: Και οι δύο ζώνες "other" και "heap admin" είναι αρκετά μεγάλες. Αυτό μας λέει ότι υπάρχουν πολλές μικρές κατανομές που έχουν γίνει από ποικίλες θέσεις. Η εξάλειψη τους θα είναι δύσκολη, αλλά εάν μπορέσουν να ομαδοποιηθούν τότε οι μεμονωμένες κατανομές μπορούν να γίνουν μεγαλύτερες και η επιβάρυνση του "heap admin" μπορεί να μειωθεί.

note: (itstool) path: section/title
en: Caveats
el: Προειδοποιήσεις

note: (itstool) path: section/p
en: There are a couple of things to watch out for: Firstly, spacetime is only reported as a percentage, you have to compare it to the overall size of the program to decide if the amount of memory is worth pursuing. The graph, with its kilobyte vertical axis, is good for this.
el: Υπάρχουν μερικά πράγματα που θα πρέπει να προσέξετε: Αρχικά, ο χωρόχρονος εμφανίζεται μόνο ως ποσοστό, πρέπει να το συγκρίνετε με το γενικό μέγεθος του προγράμματος για να αποφασίσει εάν το ποσό μνήμης αξίζει να δαπανηθεί. Η γραφική παράσταση, με τον κάθετο άξονα σε kilobyte, είναι ιδανικό για κάτι τέτοιο.

note: (itstool) path: section/p
en: Secondly, <app>Massif</app> only takes into account the memory used by your own program. Resources like pixmaps are stored in the X server and aren't considered by <app>Massif</app>. In the <app>Swell Foop</app> example we have actually only moved the memory consumption from client-side pixbufs to server-side pixmaps. Even though we cheated there are performance gains. Keeping the image data in the X server makes the graphics routines quicker and removes a lot of inter-process communication. Also, the pixmaps will be stored in a native graphics format which is often more compact than the 32-bit RGBA format used by gdk_pixbuf. To measure the effect of pixmaps, and other X resources use the <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link> program.
el: Αφετέρου, το <app>Massif</app> λαμβάνει υπόψη μόνο τη μνήμη που χρησιμοποιείται από τα προγράμματα σας. Οι πόροι όπως τα pixmaps αποθηκεύονται στον διακομιστή X και δεν εξετάζονται από το <app>Massif</app>. Στο παράδειγμα με το <app>Swell Foop</app> στην πραγματικότητα έχουμε μετακινήσει την κατανάλωση μνήμης μόνο την pixbufs από την πλευρά του προγράμματος πελάτη στα pixmaps από την πλευρά του διακομιστή. Αν και κάναμε μία μικρή απάτη, υπάρχουν κέρδη στην απόδοση. Αν κρατήσουμε τα δεδομένα εικόνας του διακομιστή X καθιστά τις ρουτίνες γραφικής αναπαράστασης γρηγορότερες και αφαιρεί πολύ διεπεξεργαστική επικοινωνία. Επίσης, τα pixmaps θα αποθηκευτούν σε μία εγγενή μορφή γραφικών που είναι συχνά συμπαγέστερο από τη μορφή 32-δυαδικών RGBA που χρησιμοποιείται από το gdk_pixbuf. Για να μετρηθεί η επίδραση των pixmaps και άλλων πόρων του διακομιστή X χρησιμοποιήστε το πρόγραμμα <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link>.
