Discussion :

[Deaf]

Bonjour,

Je suis actuellement dans le développement d'une appli localisée.

De manière classique, j'ai externalisé les messages (pour les logs comme pour l'utilisateur) dans des fichiers au format properties que je récupère via un ResourceBundle.

Jusqu'à présent, j'utilisais la méthode String.format pour le formatage, mais je suis en train de reconsidérer la question pour utiliser MessageFormat.format.
La raison de ceci est le format plus lisible des champs variables pour les non-informaticiens...

Après quelques tests, le MessageFormat semble plus lent que le String.format (en moyenne 20% de temps en plus).

Je cherche donc un moyen d'optimiser l'utilisation du MessageFormat.
Après quelques tests, la seule solution que j'ai trouvée est la suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
    // Map synchronisée et faible
    private final Map<Key<String, Locale>, MessageFormat> formatters = Collections.<Key<String, Locale>, MessageFormat> synchronizedMap(new WeakHashMap<Key<String, Locale>, MessageFormat>());
 
    public String format(final Locale locale, final String pattern, final Object... params)
    {
        // Récupération du formatteur existant
        final Key<String, Locale> key = new Key<String, Locale>(pattern, locale);
        MessageFormat formatter = formatters.get(key);
 
        // Ou création si nécessaire
        if (formatter == null)
        {
            formatter = new MessageFormat(pattern, locale);
            formatters.put(key, formatter);
        }
 
        // MessageFormat n'est pas thread-safe
        synchronized (formatter)
        {
            return formatter.format(params);
        }
    }

Elle ne me satisfait pas complètement car la taille de la map peut très vite augmenter. Le choix d'une WeakHashMap permet de la purger régulièrement, mais cela oblige aussi à recréer régulièrement les formatteurs.

Voyez-vous une meilleure solution?
Celle proposée vous semble-t-elle saine?

[dinobogan]

Si tu cherches à améliorer les temps de calcul, tu explores les pistes classiques :

• tout mettre en mémoire, malheureusement, la mémoire n'est pas infinie
• changer de machine pour des processeurs qui "déchirent leur race", malheureusement on est souvent obligé d'utiliser la super machine achetée il y a 64 ans par l'arrière grand-père de l'actuel chef d'entreprise
• totalement repenser l'algorithme de calcul, mais les chefs et le client ne seront pas content car ça repousse la livraison
• soigner l'implémentation de l'algorithme, mais là encore ouille la date de livraison
• autre... on sait jamais

Ton approche me semble correcte.

Avant de compliqué tout, es-tu sûr et certain d'avoir besoin d'améliorer le temps de réponse ?

[Deaf]

Merci pour ta réponse.

Pour toutes les contraintes pro, on oublie!
Pour ce problème là, je suis dans le cadre d'un projet perso et j'en profite pour explorer différentes pistes et trouver une solution qui soit suffisamment élégante et qui ne plombe pas trop les perfs non plus.

Comme cette méthode est appelée, entre autres, pour écrire des logs, je pense que l'aspect perf est un peu plus important que pour une interface utilisateur. Il ne faudrait pas qu'en niveau TRACE/DEBUG, des ralentissements se fassent sentir...

Disons que j'essaie de voir les avantages/inconvénients des deux méthodes de formatage standards (String.format & MessageFormat.format) et les meilleures façons de s'en servir.

Donc je reste ouvert à tout commentaire!