Lags dans l'éditeur de Méthode?

Testé sur macOS 10.14.6 (18G3020) et 4D v18.0 build 18.248238

Je pensais que c’était dû à l’utilisation de la version v17 en 32 bit, mais là, j’utilise maintenant la v18 (donc 64 bit) et je rencontre toujours le même problème de lags important lorsque je saisis du texte dans l’éditeur de méthode ? D’où peut provenir ce problème ? est-ce normal ? c’est relativement récent je n’avais pas ce problème avant.

C’est quand même contraignant lorsque l’on saisit du texte de devoir attendre avant que celui-ci n’apparaisse à l’écran ! et pourtant je ne tape qu’avec 2 doigts :oops:

à tout hasard, as-tu beaucoup de méthodes et/formulaires ouverts ?

Cela dépend de ce que tu appelles beaucoup, je suis en phase de restructuration du code (suppression des plug-ins 4D Write et 4D View pour passage en 64bit) donc oui j’ai 18 méthodes d’ouvertes mais je ne vois pas en quoi cela devrait ralentir la saisie de texte au sein d’une seule fenêtre ?

Je peux me tromper, mais je n’ai pas l’impression qu’il y ait un lien de cause à effet.

J’en profite pour demander si en passant à la v18 une ancienne base il faut revoir les paramétrages de la mémoire cache de ma base ? Si oui dans quel sens ?

Peut-il y avoir une incidence en mode développement comme il y en avait en 32 bit ?

En 32 bits, beaucoup de fenêtres freinait pas mal, mais c’était plus les rafraichissements “en général” que l’éditeur de code qui s’en ressentaient. Ça se voit vite, tu fermes tout et si ça rame encore c’est autre chose ; je pense plutôt que c’est autre chose, genre une interférence avec un autre programme, car 4D est franchement véloce en 64bit, je n’ai jamais remarqué ce que tu décris et 18 fenêtres n’a rien “d’étouffant” chez moi.

Paramétrages du cache : complètement différent, tu peux par exemple le changer à la volée. J’ai juste l’impression qu’il ne faut pas en mettre trop (c’est tentant, en 64…), mais pas encore assez de recul.

Je ne sais pas mais devine ce que tu appelles lag.
Je n’ai pas le même problème que toi mais j’ai observé que, sans taper plus vite que Lucky Luke, j’arrive à doubler l’éditeur de méthode.

Ex, je colle MaVar après un If, puis veux taper :=…
4D met un certain temps à interpréter ma frappe, il décale la ligne de la variable et, quand je tape :=, le curseur saute, ce qui fait que := se trouve devant la variable.
Je ne comprends pas trop la logique de cette anomalie qui m’arrive souvent…

Ah, vous n’êtes pas Gamer… :mrgreen:

Cf. définition de https://fr.wiktionary.org/wiki/lagLag> en français.
Anglicisme désignant la lenteur d’un ordinateur au démarrage ou dans le processus d’une tâche.

J’ai également remarqué que lorsque je tape “:=” cela est encore plus lent mais également parfois le simple fait de rajouter une ligne, etc… cela dépend peut-être aussi de contexte (position au sein d’une boucle ou Au cas ou, etc…

C’est un changement relativement récent (peut-être l’introduction d’ORDA ?).
Y a t’il une optimisation possible pour atténuer cette problématique qui est fatigante à la longue :?:

Comme dit plus haut, je ne remarque rien de tel ni en v18, ni en v17 64b, orda opérationnel depuis des lustres ; je trouve même 4D véloce en 64, ça change du 32. En plus les 2 machines que j’utilise sont franchement surannées (un macPro de 2008 et un macbook de 2010). Donc j’essaierais de chercher ailleurs : pas d’appeler sur événement ? pas de programme autre que 4D susceptible d’interférer ? etc.

PS : si, tout de même, j’avais oublié un cas où j’ai des latences importantes.
Lorsque je développe en distant sur du wan et que je code en même temps qu’un traitement “de masse” est en cours, ou que la fenêtre de recherche est en train de (tenter de) retrouver je ne sais quoi, l’éditeur se met à ramer de façon notoire (pour ne pas dire irritante). Mais ça reste assez particulier.

Bonjour,

Un de mes collègues qui bosse sur Mac a le même problème.

Voilà les tests qu’on a réalisés, des fois que ça puisse aider :

  • On démarre 4D et on ouvre une seule méthode, dans laquelle il y a une trentaine de lignes qui manipulent une chaîne (pas de manipulation de table, pas de lecture de champs). On constate une forte latence entre la saisie et l’affichage. Dans la mesure où il n’y a qu’une seule méthode d’ouverte, ça exclu la possibilité que cette latence soit due à un trop grand nombre de fenêtre ou d’onglets ouverts (dans notre cas du moins).

  • Si on commente tout le code de la méthode, la latence disparaît.

  • Si on décommente le code progressivement, la latence revient tout aussi progressivement. elle ne semble pas apparaître à cause d’une ligne en particulier.

  • On observe aussi une latence dans le scroll, quand on fait les tests sur une méthode suffisamment longue.

  • Même si cette latence semble au début être proportionnelle au nombre de lignes non commentées dans le code, elle semble s’arrêter à un certain plafond. On a sensiblement la même latence sur une méthode de 30 lignes que sur une méthode de 300.

  • Le problème se produit autant en mode Client-Serveur qu’en Mono.

  • Le problème se produit qu’on utilise les onglets ou non (Onglets désactivés dans les paramètres, redémarrage de 4D, problème toujours présent)

La seule chose qui ait eu un impact, c’est la version d’OSX utilisée : L’ordi sur lequel on a fait les tests est sous Catalina, mais si on tente la même chose sur un ordi qui est sous High Sierra, on a aucune latence.

On est sur 4D v18 build 18.246707 sur tous les ordis mentionnés.

Merci pour le retour :!: ça fait plaisir :oops: de ne plus se sentir seul…

Pour rappel: je fais le constat de mon coté alors que mon OS est macOS 10.14.6 (MOJAVE).

Quelle est la taille de votre structure(base) ? le nombre de variables peut-il avoir un rôle ?

La structure contient une soixantaine de tables pour environ 1800 champs.

La petite méthode sur laquelle on a testé au début contient 7 variables locales, dont un paramètre d’entrée et une valeur de retour. En voici le code, si jamais vous voulez tester dessus.

La grosse méthode utilise plusieurs dizaines de variables, mais la latence semble être identique donc je ne suis pas sûr que ça ait une incidence.

<code 4D>
//CLIENT_VERIF_IBAN ( txtIBAN )
C_BOOLÉEN($0)
C_RÉEL($rCalcul)
C_ENTIER LONG($ePosition)
C_TEXTE($1;$txtAlphabet;$txtIbanNumerique;$txtIbanRecompose)

$1:=Chaine_format_alphanum ($1)

Si ($1#"")

$rCalcul:=0
$txtAlphabet:="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
$txtIbanNumerique:=""

$1:=Majusc($1)

  //On supprime les 4 premiers caracteres de la chaine pour les ajouter à la fin
$1:=Sous chaîne($1;5)+Sous chaîne($1;1;4)

  //On boucle sur la chaîne et on remplace les alpha par la position dans l'alphabet + 9 (Ex A=1+9=10)
Boucle ($i;1;Longueur($1))
	$ePosition:=Position($1[$i];$txtAlphabet;*)
	$txtIbanNumerique:=$txtIbanNumerique+Choisir($ePosition=0;$1[$i];Chaîne($ePosition+9))
Fin de boucle 

  //Le chiffre est tellement long que 4D en perd les détails, on est obligé de faire le modulo en plusieurs fois pour que ça fonctionne
Si (Longueur($txtIbanNumerique)>10)
	
	$txtIbanRecompose:=Chaîne(Modulo(Num(Sous chaîne($txtIbanNumerique;1;10));97))+Sous chaîne($txtIbanNumerique;11)
	
	Si (Longueur($txtIbanRecompose)>10)
		$txtIbanRecompose:=Chaîne(Modulo(Num(Sous chaîne($txtIbanRecompose;1;10));97))+Sous chaîne($txtIbanRecompose;11)
	Fin de si 
	
Sinon 
	$txtIbanRecompose:=$txtIbanNumerique
Fin de si 

$rCalcul:=Num($txtIbanRecompose)
$0:=(Modulo($rCalcul;97)=1)

Sinon
$0:=Faux
Fin de si
</code 4D>

Bonjour,

Je travaille sur une structure plus grosse et en V17 avec un mac cacochyme (un vieux Mac Mini de 9 ans d’âge) sans percevoir le phénomène : ce n’est donc pas une fatalité !

Je travaille en général directement sur la version en production (sur 4D serveur) ce qui n’est pas bien je sais !

Les seules fois où j’ai rencontré le phénomène c’est lorsque je travaille à distance sur le 4D Server d’une filiale située à l’étranger au travers d’une connexion relativement lente.

J’en déduis que c’est une question de liaison entre l’application locale et le serveur.

Dans votre cas la base 4D est ouverte en local ou en accès 4D Server ?

Si elle est ouverte en local, où est elle hébergée ? Sur un disque local ou sur un réseau ?

Jp

Non, là il s’agit (sacrilège) d’un développement sur une base en MONOPOSTE en local !
C’est d’ailleurs pour cela que je ne comprends absolument pas les lenteurs constatées…

Juste pour info quelle version de l’OS utilisez-vous et quelle version de 4D ?

4D V17.3 - Mac OS 10.11.6 (El Capitan) sur un Mac Mini (mi 2011) et Mac OS 10.14.5 (Mojave) sur un Mac Book Pro 2019

TVB sur chacune des deux configurations, que ce soit en travail sur une base server ou une base en local.

Les bases sont bien sûr ouvertes en interprété. 4D contrôle (interprète ?) le code à la volée : visiblement c’est cette action qui prend du temps chez vous, ce qui expliquerait pourquoi le code commenté ne provoque pas de lags.

On est d’accord qu’on parle du mode développement en saisie du code dans l’éditeur de méthode, pas de l’utilisation de 4D en interprété en général.

C’est là que je constate des lenteurs lors de saisie de texte dans la fenêtre d’une méthode.
Visiblement il y a quelque chose qui fait que des lenteurs importantes apparaissent et je ne sais pas où chercher… :cry:

J’ai du mal à croire que ce soit l’OS quand cet emmerdement n’a pas l’air de toucher la grande majorité : ça se saurait, non ?

Ce serait pas mal qu’on sache si ça arrive quelle que soit la base (y compris une base nouvellement créée), et si ça se produit toujours en n’ayant que 4D de lancé pour écarter l’hypothèse d’une interférence avec un autre programme - je me souviens par exemple qu’à une époque https://forums.4d.com/Post/FR/21542366/1/21714279#21542367TeamViewer> donnait des petits boutons à 4D.

Oui, j’avais espoir que ce soit Catalina qui nous fasse des misères, mais si ça se produit sur d’autres versions, ça ne colle pas.

On va tâcher de faire les tests que vous proposez.

Oui tout à fait : mode développement !

Mais en mode développement, le code est quand même interprété par 4D pendant l’écriture (la preuve, il signale les fautes de frappe et de syntaxe). C’est ça qui a l’air de coincer dans votre cas.

Quelques précisions supplémentaires:

  • j’utilise la langue française pour le développement (cela peut éventuellement constituer un element différenciant dans le comportement de l’analyseur syntaxique ?)
  • c’est une ancienne base convertie maintes fois, qui possède une centaine de tables
  • utilisation de l’UTF et du langage objet activé
  • J’ai également l’application Prolexis d’activé sur le poste, possible effet de bord ?