Discussion :

[Clorish]

Je cherche a compiler un programe comportant des unitees avec fichiers includes.
Dans ces fichier includes, je defini des fonctions qui renvoient des ressources sous formes de chaines string.
Autrement dit, ces fonctions renvoie la chaine hexadecimale representative du fichier binaire.

Le fait est que la chaine renvoyee fait pres de 15ko min voir bien plus.
J'ai noté un tres long temps de compilation (pres d'une minute) pour des chaines allant jusqu'a 150Ko

Comment optimiser cela sans passer bien sur par les ressources car le but etant de les supprimer.

[MD Software]

Ben, si tu travailles en retour de fonctions, je dirais que tu es plus long que si tu travailles en paramètres var.
Tu as essayé en passant des var plutôt que d'utiliser des fonctions ?

[Clorish]

non .. mais le gain de temps et consequent ? si ca se joue a une ou 2s sur 60 c pas tres interessant :/

[MD Software]

Je pense que ça peut être conséquent, mais c'est à tester.

[Reisubar]

Je ne vois pas trop en quoi cela améliorerait la rapidité. Lorsqu'une fonction retourne une AnsiString, c'est une référence (donc une adresse) qui est retournée, ce qui revient à peu au même que prendre cette référence en paramètre, non ?

[MD Software]

Je dirais que tout se joue avec l'optimisateur. En effet, c'est un passage d'adresse, mais le fait de passer par un paramète est optimisable.

Celà dit, c'était juste une idée. Je pense qu'il faut tester. Je ne garantie pas une accelération.

[djo.mos]

La compilation est lente car tous les ressources seront stockés dans l'exe.
Le seul moyen d'accelerer la chose et de stocker ces données dans des fichiers séparés, et à l'appel d'une fonction, celle ci doit charger ce fichier, le décoder, et la, retourner sous forme de chaine.

[Clorish]

Le seul moyen d'accelerer la chose et de stocker ces données dans des fichiers séparés, et à l'appel d'une fonction, celle ci doit charger ce fichier, le décoder, et la, retourner sous forme de chaine.

L'ecriture d'un fichier binaire sous forme de chaine hexadecimale est justement pour se passer de fichier paralleles. C'est pour inclure les fichier dans le DCU, ce que ne fait pas les .Res meme si au niveau du developpement j'ai separe mes "ressources" dans un include.

[sjrd]

Tu pourrais diviser la taille de tes chaînes par 2, ce qui visiblement aura déjà un bel effet, simplement en stockant la représentation caractère par caractère de ton fichier plutôt que sa représentation hexadécimale (2 caractères représentent un octet : quel gâchis ).
En pratique ça revient à transformer :

Code :

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

MaChaine = '0015207E41'

en

Code :

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

MaChaine = #0#21' ~A'

Ou si tu préfères garder de l'hexa dans ton code :

Code :

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

MaChaine = #$00#$15#$20#$7E#$41

D'un tout autre côté, il est peut-être aussi possible de reconsidérer la façon d'obtenir les chaînes. Par exemple au lieu de fonctions des tableaux. Ce que tu fais (ressources dans le code source) est déjà vraiment limite, alors ce n'est pas étonnant que tu ais des problème, et donc qu'il faille penser au mieux la suite.

[Clorish]

Oui je me suis pose la question sur les differentes moyens d'initialiser des grands types de donnes tout en restant assez lisible ....

Le but etant d'arriver a remplir d'une maniere x ou y un TBitmap avec une image non chargee depuis un fichier externe ou une ressource.

Le probleme est survenu quand j'ai commencé a dessiner un composant avec les fleches et le curseur d'une scrollbar personalisée.

je me suis retrouve avec 2 images de 10x10 pixels trop petite pour etre gerees par uen ressources (trop lourd) et un peut trop complexue pour ecrire la 100aine de lignes de codes qui dessine quasiement pixel par pixel chacune des images.

Cette idee de gestion Hexa comme dans les DFM me parraissait une bonne idee. Du coup j'adapte comme je peux

Je suis ouvert a toutes propositions.
Pour les petites images du genre 10x10 comme celles precidees plus haut c'est tres bien mais j'aurais aimé les adapter a un systeme plu complexe comme pour la gestion des "skins".
C'est a dire faire des images aussi complexe et belels que les skin sans forcement donner la possibilite de changer de "skin" .. je sais pas si ca suis toujours ...

Le but etant d'aigailler un logiciel avec de jolis graphiques sans devoir se trimbaler N fichier Res se lon les composants.