Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la
"somme" de chaines de caractères sous VB6 (allocation d'espace cible
puis recopie de la chaine 1 puis de la chaine 2), tandis que certains
langages (VB.NET par exemple) proposent une méthode .Append capable
de réserver un espace mémoire à la suite de la chaine 1, pour n'avoir
qu'à recopier la chaine 2. Dans mon cas, j'ai un tableau contenant
beaucoup (quelques milliers)
de "petites" String (entre 10 et 50 octets), que j'ai besoin de
concaténer dans une seule chaine résultante. Or je me suis aperçu que
les temps de réponses augmentent de manière exponentielle avec le
nombre de petites chaines. Pour l'instant, pour première optimisation,
j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux,
faire des chaines plus petites, et au final faire
chaine1+chaine2+chaine3+chaine4. Et ça va déjà près de deux fois plus
vite qu'en faisant une seule boucle FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus
efficace, s'appuyant par exemple sur une notion de dichotomie, qui
permettrait d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon
besoin? Merci d'avance pour votre aide.
JN BERGER
Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la
"somme" de chaines de caractères sous VB6 (allocation d'espace cible
puis recopie de la chaine 1 puis de la chaine 2), tandis que certains
langages (VB.NET par exemple) proposent une méthode .Append capable
de réserver un espace mémoire à la suite de la chaine 1, pour n'avoir
qu'à recopier la chaine 2. Dans mon cas, j'ai un tableau contenant
beaucoup (quelques milliers)
de "petites" String (entre 10 et 50 octets), que j'ai besoin de
concaténer dans une seule chaine résultante. Or je me suis aperçu que
les temps de réponses augmentent de manière exponentielle avec le
nombre de petites chaines. Pour l'instant, pour première optimisation,
j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux,
faire des chaines plus petites, et au final faire
chaine1+chaine2+chaine3+chaine4. Et ça va déjà près de deux fois plus
vite qu'en faisant une seule boucle FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus
efficace, s'appuyant par exemple sur une notion de dichotomie, qui
permettrait d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon
besoin? Merci d'avance pour votre aide.
JN BERGER
Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la
"somme" de chaines de caractères sous VB6 (allocation d'espace cible
puis recopie de la chaine 1 puis de la chaine 2), tandis que certains
langages (VB.NET par exemple) proposent une méthode .Append capable
de réserver un espace mémoire à la suite de la chaine 1, pour n'avoir
qu'à recopier la chaine 2. Dans mon cas, j'ai un tableau contenant
beaucoup (quelques milliers)
de "petites" String (entre 10 et 50 octets), que j'ai besoin de
concaténer dans une seule chaine résultante. Or je me suis aperçu que
les temps de réponses augmentent de manière exponentielle avec le
nombre de petites chaines. Pour l'instant, pour première optimisation,
j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux,
faire des chaines plus petites, et au final faire
chaine1+chaine2+chaine3+chaine4. Et ça va déjà près de deux fois plus
vite qu'en faisant une seule boucle FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus
efficace, s'appuyant par exemple sur une notion de dichotomie, qui
permettrait d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon
besoin? Merci d'avance pour votre aide.
JN BERGER
Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la "somm e" de
chaines de caractères sous VB6 (allocation d'espace cible puis recopie de la
chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
exemple) proposent une méthode .Append capable de réserver un espace mémoire
à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
"petites" String (entre 10 et 50 octets), que j'ai besoin de concaténer dans
une seule chaine résultante. Or je me suis aperçu que les temps de r éponses
augmentent de manière exponentielle avec le nombre de petites chaines.
Pour l'instant, pour première optimisation, j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux, faire
des chaines plus petites, et au final faire chaine1+chaine2+chaine3+chain e4.
Et ça va déjà près de deux fois plus vite qu'en faisant une seule boucle
FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus efficace,
s'appuyant par exemple sur une notion de dichotomie, qui permettrait
d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon beso in?
Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la "somm e" de
chaines de caractères sous VB6 (allocation d'espace cible puis recopie de la
chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
exemple) proposent une méthode .Append capable de réserver un espace mémoire
à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
"petites" String (entre 10 et 50 octets), que j'ai besoin de concaténer dans
une seule chaine résultante. Or je me suis aperçu que les temps de r éponses
augmentent de manière exponentielle avec le nombre de petites chaines.
Pour l'instant, pour première optimisation, j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux, faire
des chaines plus petites, et au final faire chaine1+chaine2+chaine3+chain e4.
Et ça va déjà près de deux fois plus vite qu'en faisant une seule boucle
FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus efficace,
s'appuyant par exemple sur une notion de dichotomie, qui permettrait
d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon beso in?
Bonjour,
J'ai un souci de performances lié au fonctionnement interne de la "somm e" de
chaines de caractères sous VB6 (allocation d'espace cible puis recopie de la
chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
exemple) proposent une méthode .Append capable de réserver un espace mémoire
à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
"petites" String (entre 10 et 50 octets), que j'ai besoin de concaténer dans
une seule chaine résultante. Or je me suis aperçu que les temps de r éponses
augmentent de manière exponentielle avec le nombre de petites chaines.
Pour l'instant, pour première optimisation, j'ai juste implémenté un
comptage du nombre de lignes du tableau, pour couper en 4 morceaux, faire
des chaines plus petites, et au final faire chaine1+chaine2+chaine3+chain e4.
Et ça va déjà près de deux fois plus vite qu'en faisant une seule boucle
FOR.
Je pense toutefois qu'il doit exister un système beaucoup plus efficace,
s'appuyant par exemple sur une notion de dichotomie, qui permettrait
d'optimiser réellement la chose.
Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon beso in?
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
internet.fr> wrote:
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréquente
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
<j-n.enlevezmoi.ber...@club- internet.fr> wrote:
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréquente
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
internet.fr> wrote:
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréquente
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
internet.fr> wrote:
> Bonjour,
> J'ai un souci de performances lié au fonctionnement interne de la "so mme" de
> chaines de caractères sous VB6 (allocation d'espace cible puis recopi e de la
> chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
> exemple) proposent une méthode .Append capable de réserver un espac e mémoire
> à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
> Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
> "petites" String (entre 10 et 50 octets), que j'ai besoin de concatén er dans
> une seule chaine résultante. Or je me suis aperçu que les temps de réponses
> augmentent de manière exponentielle avec le nombre de petites chaines.
> Pour l'instant, pour première optimisation, j'ai juste implémenté un
> comptage du nombre de lignes du tableau, pour couper en 4 morceaux, fai re
> des chaines plus petites, et au final faire chaine1+chaine2+chaine3+cha ine4.
> Et ça va déjà près de deux fois plus vite qu'en faisant une seu le boucle
> FOR.
> Je pense toutefois qu'il doit exister un système beaucoup plus effica ce,
> s'appuyant par exemple sur une notion de dichotomie, qui permettrait
> d'optimiser réellement la chose.
> Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon be soin?
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréque nte
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
Néanmoins, comme l'a exprimé LE TROLL, si tu peux réaliser ton outp ut
directement dans un flux, tel un fichier, un socket, ... tu auras un
gain énorme en performances.
Voici une implémentation possible de la première méthode:
'Dans un module de classe
Option Explicit
Private mInternal As String
Private mLenB As Long 'en bytes
Private mBlocSize As Long 'en charactères
Public Property Get BlocSize() As Long
BlocSize = mBlocSize
End Property
Public Property Let BlocSize(Value As Long)
mBlocSize = Value
End Property
Public Sub Alloc(BlocCount As Long)
If (BlocCount > 0) Then
mInternal = mInternal & String$(mBlocSize * BlocCount,
vbNullChar)
ElseIf (BlocCount < 0) Then
mInternal = Left$(mInternal, Len(mInternal) + mBlocSize *
BlocCount)
End If
End Sub
Public Function ToString() As String
ToString = Left$(mInternal, mLenB / 2)
End Function
Public Sub Clear(Optional DeAlloc As Boolean = False)
mLenB = 0
If (DeAlloc) Then
mInternal = String$(mBlocSize, vbNullChar)
End If
End Sub
Public Sub Append(Text As String)
Dim AllocLength As Long
AllocLength = LenB(Text) - (LenB(mInternal) - mLenB)
If (AllocLength > 0) Then
Alloc (AllocLength / mBlocSize + 1)
End If
Mid$(mInternal, mLenB / 2 + 1) = Text
mLenB = mLenB + LenB(Text)
End Sub
Private Sub Class_Initialize()
mLenB = 0
mBlocSize = 1024
mInternal = String$(mBlocSize, vbNullChar)
End Sub
'Un exemple d'utilisation
Dim a As New StringBuilder
Dim i As Long
For i = 0 To 5000
a.Append "Test"
a.Append "Toto"
Next i
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER" <j-n.enlevezmoi.ber...@club-
internet.fr> wrote:
> Bonjour,
> J'ai un souci de performances lié au fonctionnement interne de la "so mme" de
> chaines de caractères sous VB6 (allocation d'espace cible puis recopi e de la
> chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
> exemple) proposent une méthode .Append capable de réserver un espac e mémoire
> à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
> Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
> "petites" String (entre 10 et 50 octets), que j'ai besoin de concatén er dans
> une seule chaine résultante. Or je me suis aperçu que les temps de réponses
> augmentent de manière exponentielle avec le nombre de petites chaines.
> Pour l'instant, pour première optimisation, j'ai juste implémenté un
> comptage du nombre de lignes du tableau, pour couper en 4 morceaux, fai re
> des chaines plus petites, et au final faire chaine1+chaine2+chaine3+cha ine4.
> Et ça va déjà près de deux fois plus vite qu'en faisant une seu le boucle
> FOR.
> Je pense toutefois qu'il doit exister un système beaucoup plus effica ce,
> s'appuyant par exemple sur une notion de dichotomie, qui permettrait
> d'optimiser réellement la chose.
> Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon be soin?
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréque nte
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
Néanmoins, comme l'a exprimé LE TROLL, si tu peux réaliser ton outp ut
directement dans un flux, tel un fichier, un socket, ... tu auras un
gain énorme en performances.
Voici une implémentation possible de la première méthode:
'Dans un module de classe
Option Explicit
Private mInternal As String
Private mLenB As Long 'en bytes
Private mBlocSize As Long 'en charactères
Public Property Get BlocSize() As Long
BlocSize = mBlocSize
End Property
Public Property Let BlocSize(Value As Long)
mBlocSize = Value
End Property
Public Sub Alloc(BlocCount As Long)
If (BlocCount > 0) Then
mInternal = mInternal & String$(mBlocSize * BlocCount,
vbNullChar)
ElseIf (BlocCount < 0) Then
mInternal = Left$(mInternal, Len(mInternal) + mBlocSize *
BlocCount)
End If
End Sub
Public Function ToString() As String
ToString = Left$(mInternal, mLenB / 2)
End Function
Public Sub Clear(Optional DeAlloc As Boolean = False)
mLenB = 0
If (DeAlloc) Then
mInternal = String$(mBlocSize, vbNullChar)
End If
End Sub
Public Sub Append(Text As String)
Dim AllocLength As Long
AllocLength = LenB(Text) - (LenB(mInternal) - mLenB)
If (AllocLength > 0) Then
Alloc (AllocLength / mBlocSize + 1)
End If
Mid$(mInternal, mLenB / 2 + 1) = Text
mLenB = mLenB + LenB(Text)
End Sub
Private Sub Class_Initialize()
mLenB = 0
mBlocSize = 1024
mInternal = String$(mBlocSize, vbNullChar)
End Sub
'Un exemple d'utilisation
Dim a As New StringBuilder
Dim i As Long
For i = 0 To 5000
a.Append "Test"
a.Append "Toto"
Next i
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
internet.fr> wrote:
> Bonjour,
> J'ai un souci de performances lié au fonctionnement interne de la "so mme" de
> chaines de caractères sous VB6 (allocation d'espace cible puis recopi e de la
> chaine 1 puis de la chaine 2), tandis que certains langages (VB.NET par
> exemple) proposent une méthode .Append capable de réserver un espac e mémoire
> à la suite de la chaine 1, pour n'avoir qu'à recopier la chaine 2.
> Dans mon cas, j'ai un tableau contenant beaucoup (quelques milliers) de
> "petites" String (entre 10 et 50 octets), que j'ai besoin de concatén er dans
> une seule chaine résultante. Or je me suis aperçu que les temps de réponses
> augmentent de manière exponentielle avec le nombre de petites chaines.
> Pour l'instant, pour première optimisation, j'ai juste implémenté un
> comptage du nombre de lignes du tableau, pour couper en 4 morceaux, fai re
> des chaines plus petites, et au final faire chaine1+chaine2+chaine3+cha ine4.
> Et ça va déjà près de deux fois plus vite qu'en faisant une seu le boucle
> FOR.
> Je pense toutefois qu'il doit exister un système beaucoup plus effica ce,
> s'appuyant par exemple sur une notion de dichotomie, qui permettrait
> d'optimiser réellement la chose.
> Quelqu'un aurait-il sous la main un code qui pourrait satisfaire mon be soin?
Hello,
Le problème vient comme tu l'as indiqué de la réallocation fréque nte
de mémoire.
Il y a au moins deux solutions qui permettent de résoudre le problème:
1/ Préallocation de blocs de mémoires par String$, concaténation par
le mot clé (et non la fonction) Mid
2/ Allocation par bloc d'un tableau de string (avec allocations par
blocs), la chaine finale étant obtenue par préallocation d'une chaine
par String et copie par mid, à l'aide des peu couteuses opérations
LenB (déférencement d'un pointeur) et division finale par 2 (ce que
fait Len, si ce n'est qu'il le fait pour chaque String).
A priori, la deuxième solution demande souvent des petits blocs de
mémoires, sauf pour la concaténation finale, alors que la première
demande peu souvent de plus gros blocs. (une combinaison des deux
méthodes est probablement envisageable.
Néanmoins, comme l'a exprimé LE TROLL, si tu peux réaliser ton outp ut
directement dans un flux, tel un fichier, un socket, ... tu auras un
gain énorme en performances.
Voici une implémentation possible de la première méthode:
'Dans un module de classe
Option Explicit
Private mInternal As String
Private mLenB As Long 'en bytes
Private mBlocSize As Long 'en charactères
Public Property Get BlocSize() As Long
BlocSize = mBlocSize
End Property
Public Property Let BlocSize(Value As Long)
mBlocSize = Value
End Property
Public Sub Alloc(BlocCount As Long)
If (BlocCount > 0) Then
mInternal = mInternal & String$(mBlocSize * BlocCount,
vbNullChar)
ElseIf (BlocCount < 0) Then
mInternal = Left$(mInternal, Len(mInternal) + mBlocSize *
BlocCount)
End If
End Sub
Public Function ToString() As String
ToString = Left$(mInternal, mLenB / 2)
End Function
Public Sub Clear(Optional DeAlloc As Boolean = False)
mLenB = 0
If (DeAlloc) Then
mInternal = String$(mBlocSize, vbNullChar)
End If
End Sub
Public Sub Append(Text As String)
Dim AllocLength As Long
AllocLength = LenB(Text) - (LenB(mInternal) - mLenB)
If (AllocLength > 0) Then
Alloc (AllocLength / mBlocSize + 1)
End If
Mid$(mInternal, mLenB / 2 + 1) = Text
mLenB = mLenB + LenB(Text)
End Sub
Private Sub Class_Initialize()
mLenB = 0
mBlocSize = 1024
mInternal = String$(mBlocSize, vbNullChar)
End Sub
'Un exemple d'utilisation
Dim a As New StringBuilder
Dim i As Long
For i = 0 To 5000
a.Append "Test"
a.Append "Toto"
Next i
Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
François Picalausa wrote:Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particulier
PowerPoint. Migration faite</private>
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ;
FAQ VB: http://faq.vb.free.fr/
François Picalausa wrote:
Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particulier
PowerPoint. Migration faite</private>
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
FAQ VB: http://faq.vb.free.fr/
François Picalausa wrote:Private Sub Alloc()
ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
End Sub
Private Sub Class_Initialize()
mBlocSize = 256
ReDim mStrings(mBlocSize)
mNOL = 0
End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particulier
PowerPoint. Migration faite</private>
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ;
FAQ VB: http://faq.vb.free.fr/
François Picalausa wrote:
> Private Sub Alloc()
> ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
> End Sub
> Private Sub Class_Initialize()
> mBlocSize = 256
> ReDim mStrings(mBlocSize)
> mNOL = 0
> End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particul ier
PowerPoint. Migration faite</private>
François Picalausa wrote:
> Private Sub Alloc()
> ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
> End Sub
> Private Sub Class_Initialize()
> mBlocSize = 256
> ReDim mStrings(mBlocSize)
> mNOL = 0
> End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particul ier
PowerPoint. Migration faite</private>
François Picalausa wrote:
> Private Sub Alloc()
> ReDim Preserve mStrings(UBound(mStrings) + mBlocSize)
> End Sub
> Private Sub Class_Initialize()
> mBlocSize = 256
> ReDim mStrings(mBlocSize)
> mNOL = 0
> End Sub
Re,
Est ce que sémantiquement la variable mBlocSize ne devrait
pas plutot s'appeler mBlocsNumber, voire mNumberBlocs ?
Je vais quoi qu'il en soit bencher tout ça.
<private>Office Ultimate 2007, c'est trèèèèès cool, en particul ier
PowerPoint. Migration faite</private>
On Jul 21, 10:48 am, François Picalausa wrote:On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
Bien entendu, il faudrait bencher correctement le tout pour voir
laquelle des deux est plus rapide (Jean-Marc, si tu
m'entends ;-) )...
Ceci tient compte du fait qu'on ne cherche qu'a concaténer une chaine
de caractère. Si on souhaitais supprimer quelques caractères en in de
chaine, réaliser un "instr", ou un "mid", la première solution
présenterait un net avantage dans la facilité à écrire le code.
On Jul 21, 10:48 am, François Picalausa <fpicala...@gmail.com> wrote:
On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
<j-n.enlevezmoi.ber...@club-
Bien entendu, il faudrait bencher correctement le tout pour voir
laquelle des deux est plus rapide (Jean-Marc, si tu
m'entends ;-) )...
Ceci tient compte du fait qu'on ne cherche qu'a concaténer une chaine
de caractère. Si on souhaitais supprimer quelques caractères en in de
chaine, réaliser un "instr", ou un "mid", la première solution
présenterait un net avantage dans la facilité à écrire le code.
On Jul 21, 10:48 am, François Picalausa wrote:On Jul 20, 11:15 pm, "Jean-Nicolas BERGER"
Bien entendu, il faudrait bencher correctement le tout pour voir
laquelle des deux est plus rapide (Jean-Marc, si tu
m'entends ;-) )...
Ceci tient compte du fait qu'on ne cherche qu'a concaténer une chaine
de caractère. Si on souhaitais supprimer quelques caractères en in de
chaine, réaliser un "instr", ou un "mid", la première solution
présenterait un net avantage dans la facilité à écrire le code.