Για τα screenshots ένα
πολύ καλό free πρόγραμμα είναι το
MWSnap. Ούτε αυτό έχει όμως επιλογή για Color Mode: Paletted 8bit. Έτσι χρησιμοποιώ μετά το Corel Photo Paint για να αλλάξω το Color Mode στα screenshots. Επιλέγω όσο γίνεται μικρότερο αριθμό χρωμάτων, συνήθως 64, και σώζω πάντα σε PNG. Χάνεται βέβαια λίγη πληροφορία - ειδικά στα gradients - αλλά είναι πολύ προτιμότερο από τα artifacts που προσθέτει το JPEG γύρω από τα γράμματα. Και βέβαια τα αρχεία αποκτούν εντυπωσιακά μικρό μέγεθος (bytes). Η μείωση των χρωμάτων (από τα standard 256) εκτός του ό,τι μειώνει την παλέτα, καθιστά αποτελεσματικότερο τον αλγόριθμο συμπίεσης. Προσοχή, μιλάμε πάντα για windows screenshots, όχι φωτογραφίες!
Οι λύσεις που έχουν ανακαλυφθεί για το πρόβλημα του πλανόδιου πωλητή θα έχουν βρει σίγουρα ένα σωρό εφαρμογές σε τομείς όπως networking και αλλού. Πραγματικά όμως δε νομίζω ότι βοήθησαν ποτέ αυτούς που προκάλεσαν την αρχική διατύπωση του προβλήματος: τους πλανόδιους πωλητές. Από την εμπειρία μου ως πωλητής σε όλη σχεδόν την Ελλάδα μπορώ να πω ότι ο καθορισμός της διαδρομής δεν είναι συνήθως δύσκολη υπόθεση και εκτός από την απόσταση μεταξύ των πόλεων εξαρτάται και από πολλούς άλλους παράγοντες:
α) Αριθμός πελατών σε κάθε πόλη.
β) Ωράρια των καταστημάτων σε κάθε πόλη.
γ) Αναγκαιότητα επίσκεψης συγκεκριμένων πελατών σε συγκεκριμένες ώρες.
δ) Ύπαρξη ή όχι αξιοπρεπών ξενοδοχείων για διανυκτέρευση σε κάθε πόλη.
ε) Επικίνδυνες διαδρομές που πρέπει να αποφεύγονται νυχτερινές ώρες.
στ) Συνήθεια. Η τυχόν αλλαγή του πελατολογίου μπορεί να κάνει ένα πολύ διαφορετικό δρομολόγιο συντομότερο, αλλά τέτοιες ριζικές αλλαγές αποσυντονίζουν τον πωλητή.
Στο θέμα της ταχύτητας των αλγορίθμων νομίζω ότι έχουμε χωριστεί σε δύο στρατόπεδα:
1) Η ταχύτητα εκτέλεσης είναι πολύ σημαντική, εκτός από τις περιπτώσεις που δεν είναι.
2) Η ταχύτητα εκτέλεσης δεν είναι σημαντική, εκτός από τις περιπτώσεις που είναι.
Μου θυμίζει το παλιό ανέκδοτο:
Βασικό γνώρισμα του καπιταλισμού είναι η εκμετάλλευση ανθρώπου από άνθρωπο, ενώ στον κομμουνισμό συμβαίνει ακριβώς το αντίθετο.
Το συμπέρασμα είναι ότι πρόκειται για ένα ζήτημα κρίσης ανά περίπτωση. Και ο αποτελεσματικότερος τρόπος να αποκτηθεί η απαραίτητη κρίση είναι ο πατροπαράδοτος: τα παθήματα γίνονται μαθήματα. Και ενώ οι έξυπνοι άνθρωποι φροντίζουν να μαθαίνουν από τα λάθη τους, οι σοφοί προτιμούν να μαθαίνουν από τα λάθη των άλλων!
Παράδειγμα 1ο: Μόλις έφτιαξα ένα πρόγραμμα μετατροπής ελληνικών σε greeklish και αντιστρόφως (σε VB6). Είμαι πολύ περήφανος με τη λειτουργικότητα του προγράμματος, λαμβάνει υπ'όψη τόνους και διακρίνει τις αγγλικές λέξεις. Οι δοκιμές μου έχουν γίνει με κείμενα 100 χαρακτήρων. Μόλις του δίνω όμως ένα αρχείο 20KB να το μετατρέψει, κάνει ... κανένα δεκάλεπτο! Από τις προσπάθειες που έκανα για να επιταχύνω αυτό το πρόγραμμα έμαθα πάρα πολλά. Μετά από βελτιώσεις σε τουλάχιστον τέσσερα σημεία, το πρόγραμμα μπορούσε να μετατρέψει κείμενα 100KB σε λιγότερο από 1 sec. Το πιο χαζό λάθος ήταν το συνεχές string concatenation. Έλυσα αυτό το πρόβλημα με μία custom κλάση (BigString) που δέσμευε εκ των προτέρων την απαραίτητη μνήμη. Όταν αργότερα βγήκε το .NET είδα ότι περιλάμβανε μία έτοιμη κλάση με την ίδια ακριβώς λειτουργικότητα, τη System.Text.StringBuilder.
Παράδειγμα 2ο: Μόλις υλοποίησα τον αλγόριθμο Quick Sort για να ταξινομήσω τα ονόματα των πελατών που διαβάζω από τη βάση, για να τα βάλω έπειτα ταξινομημένα μέσα σε ένα ListBox. Ο αλγόριθμος είναι αστέρι, χαλάλι τις τρεις ώρες που με παίδεψε για να τον αντιγράψω από Pascal και να τον τεστάρω. Διαπιστώνω όμως λίγο αργότερα ότι ο χρόνος εισαγωγής χιλίων πελατών στο ListBox είναι περίπου 1000 msec και δεν υπάρχει τρόπος βελτιστοποίησης. Η διαφορά απόδοσης της ταξινόμησης με Quick Sort σε σχέση με τη Direct Insertion που είχα αρχικά είναι αντίθετα 5 msec.
Νομίζω το έχω ξαναπεί αλλά είναι ενδιαφέρον και θα το επαναλάβω. Ένας γρήγορος αλγόριθμος μπορεί να κάνει το πρόγραμμά σας πιο αργό! Αντίφαση? Όχι και τόσο. Ο γρήγορος αλγόριθμος είναι επιπλέον κώδικας για το πρόγραμμά σας και μεγαλώνει το μέγεθός του. Τα επιπλέον αυτά bytes για να έχουν την ευκαιρία να τρέξουν πρέπει να μεταφερθούν από το δίσκο στη μνήμη, και αυτό θέλει χρόνο! Αν ο αλγόριθμος χρησιμοποιηθεί μία-δύο φορές μπορεί να μην καταφέρει καν να ισοφαρίσει το αρχικό αυτό handicap. Ακόμα χειρότερα, ο αρχικός χαμένος χρόνος, με τον χρήστη να κοιτά ανυπόμονα τη splash screen είναι πολύ πιο αισθητός από ανεπαίσθητες καθυστερήσεις στη ροή του προγράμματος. Ο χρήστης μπορεί τότε να εκμεταλευτεί το χρόνο cursor:hourglass προετοιμάζοντας νοητικά τις επόμενες κινήσεις του. Δεν υπάρχει καλύτερος τρόπος να απογοητεύσετε ένα χρήστη από το να δοκιμάζετε την υπομονή του στην εκκίνηση του προγράμματος.
Η παραπάνω παρατήρηση είναι ακόμα σημαντικότερη στο web client scripting. Η ταχύτητα εκτέλεσης ενός script είναι συνήθως αμελητέα ποσότητα σε σχέση με το χρόνο downloading του κώδικα. Εδώ το μέγεθος μετράει πολύ, και δε χωράνε αστεία όπως να κατεβάζετε στον client Quick Sort αλγορίθμους ή Red Black Trees. Επιπλέον η πιο συνηθισμένη θέση για ένα script είναι στο head της HTML σελίδας, προτού δηλαδή κατέβει το παραμικρό κείμενο για να έχει κάτι ο χρήστης να ασχολείται. Μετά από μερικά δευτερόλεπτα αναμονής αντικρίζοντας τη λευκή σελίδα θα αρχίσει να κάνει κύκλους με το ποντίκι του πάνω από το μαγικό κουμπί
Back. Κλικ ... άντε γεια.
Δε θέλω να νομίσετε ότι υποτιμώ την performance. Προσωπικά έχω χρονομετρήσει σχεδόν όλες τις build-in συναρτήσεις της VB6, και έχω συγκρίνει την απόδοση πολλών διαφορετικών μεθοδολογιών από ADO και .NET μέχρι animation. Αν πάτε μία βόλτα στο MSDN θα δείτε ότι η
.NET Performance διαθέτει το δικό της αποκλειστικό τμήμα, και μάλιστα με πολύ σεβαστό μέγεθος. Αν δείτε τον όγκο του υλικού θα διαπιστώσετε ότι για ασχοληθείτε με αυτήν σοβαρά πρέπει να της διαθέσετε όλο σας το χρόνο. Υπάρχει ήδη η ειδικότητα του Performance Expert, αυτού του τύπου δηλαδή που κοιτάει λίγο το πρόγραμμά σας, κάνει ένα υποτιμητικό "τσ τσ", και με λίγες μαγικές κινήσεις μεταμορφώνει τη χελώνα σας σε F4 Fantom.
EDIT:AmmarkoV το zip ήταν τώρα 1,62ΜΒ, τι συμβαίνει? Τα textbox σου είναι τα πιο εχθρικά κοντρόλια που έχω συναντήσει μέχρι σήμερα στη ζωή μου. Νομίζω πως χρειάζονται οδηγίες χρήσεως. Τέλος, οι fun της Adrianna ζητάνε περισσότερες photo, και πιο καυτές αν γίνεται!
