PreOS Flag anti-anticrash - Page 1

juste une question : pkoi PreOS est si lent à lancer un prog? il y a au moins 0.5 seconde de chargement, même en activant le flag qui dit de ne pas restaurer l'écran... donc impossible de faire un prog kernel utilisable comme fonction en TI-Basic

Si c l'anti-crash, ce serait sympa de mettre un flag "pas d'anticrash" (qu'on pourrait d'ailleurs activer/désactiver on-calc dans un shell) pour ne pas ralentir les progs stables (et puis y a quand même l'anticrash nostub )

-

c pas le fond du pb.

Orion> et si je voulais faire un prog qui utilise ziplib (par exemple) ?

Nan, c pas l'anti-crash. Si tu veux je peux chronometrer ce qui prend du temps.
0.5 secondes ? Ton programme doit avoir un paquet de relocation je pense.


Tu peux m'envoyer ton progr de test qui fait 0.5s au demarrage ?

hmm je vais essayer de le retrouver, mais il faisait 500 octets (avec probablement une référence à une lib de 3 ko, mais pas bourrée de relocations)

Ca me paraît bizarre que ça soit les relocations, mais bon

Voilà j'ai maté les sources de PreOS et en fait ça vient bien de l'anticrash :

		; Restore handle table
		move.l	RAM_TABLE+$11*4(Pc),a2	; a2 = Heap Table
		move.l	(a2),a2
		move.l	sp,a3			; A3 = save table	
		move.w	#MAX_HANDLES-1,d5	; d5 = number of handles
		clr.b	d4			; d4 = bit number = 0
		clr.w	d3			; d3 = handle number = 0
loop			tst.l	(a2)+		; handle is allocated ?
			beq.s	OK		; NO -> OK
			btst.b	d4,(a3)		;  -> handle was not allocated before ?
			bne.s	OK		; was allocated before -> OK
			move.w	d3,d0
			bsr	kernel::Hd2Sym	; Then see if this handle is in VAT (it is a file or a folder)
			move.l	a0,d0		; Test if Null
			bne.s	OK
				move.w	d3,-(a7)
				ROM_THROW	HeapFree
				addq.w	#2,a7
OK			addq.w	#1,d3            ; increase handle number
			addq.b	#1,d4            ; increase bit number
			cmpi.b	#8,d4		; bit number == 8 ?
			bne.s	next
				addq.l	#1,a3	;  -> go to next byte in handle-info-table
				clr.b	d4	;  -> go to first bit within this byte
next			dbf	d5,loop

j'avais 643 fichiers sur ma calc + les handles temporaires (donc probablement 800 handles), et c plutôt lent...

Je te maile un test sous VTI avec 700 variables, et le chargement prend plus d'une seconde (chargement immédiat avec une caltos resettée)

Envoies a ppelissi@caramail.com. Moncompte hotmail a ete supprime.

comment ca se fait ?
inactive pdt plus de 2 mois c ca ?

oki c fait

mais c bizarre, j'ai rien reçu de hotmail me disant que mon mail était pas arrivé bla bla bla

il a ptet simplement perdu le pass

Non, je ný suis pas alle depuis 30 jours
Sinon je vais optimiser ce code.

Bon, bench. Apres optimisation (qui en + d'aller plus vite me fait econoiser qqs octets),
ca pasee a 50000 - 40000 cycles/2, la protection (Plus il y a d'handle alloues, + ca va vite),
soit relativement : 200,000, soit 10,000,000/200,000 = 50.
Donc 1/50ieme de seconde...
Mais avanca prennnait 1/40ieme de seconde. Ou est l binz ?
vais tester.

Ton fichier RAR utilise une methode de compression inconnu pour mon decompresseur.

prends winrar 3.00 c 100x mieux que le 2 (demande à thibaut pour l'url )

La flemme.

ben moi j'ai la flemme d'extraire / recompresser / renvoyer

c pas compliqué, tu fais un prog basic qui fait 700 variables, et ensuite tu lances un prog minuscule auquel il manque une lib : résultat garanti

Pkoi auquel il manque une lib v?

pour être sûr que c bien de ta faute et pas de celle du prog

Je peux faire un programme vide de test.

t courageux dis-moi faire un nouveau fichier et tout et tout

M'enerve pas.

dépêche-toi plus de nous dire pkoi c si lent

Facile ton test est foireux.
Preos recherche 4x700 fois la librairie manquante.
700x4 appels a SymFindNext ca use
700 -> recherche standard pour Relloc
700 -> recherche standard compresse pour Relloc
700 -> recherche standard pour UnRelloc
700 -> recherche standard compresse pour UnRelloc (Ok ca sert a rien mais bon )

la méthode de recherche de TI est en O(n), pas en O(ln n) ???


bon, sinon en tout cas ça revient au même avec 2 librairies pas manquantes ou une compressée

Non parce que si elles sont dans main, les libs, la recherche ira tres vite ! Il les trouvera et quittera vite. Si c compresse, ben tant pis

faut être pour mettre ses libs dans main ou alors vraiment pas se servir de sa calc pour les calculs chez moi c dans zlibs, donc évidemment

sinon je me demande pkoi la recherche est pas en O(rep * ln(fich)) où rep est le nombre de répertoires et fich le nb moyen de fichiers par répertoire Pourtant les répertoires sont triés

Parce qu'une recherche par SymFindNext est necessairement logarithmique.
Y'a rien que toi pour gueuler sur la lenteur de chargement des libraries.
Fais toi un programme qui charge les libs utilies, puis demarre le programme basic que tu souhaites (qui va utiliser un tierce progr asm)
Ca ira + vite

faut être pour mettre ses libs dans main
merde je dois être... mais c'est vrai qu'avec Universal OS, j'en ai pas
Mais il n'y avait pas d'autre endroit que main avec les anciens kernels.

Conclusion: Vive les librairies statiques, c'est beaucoup plus rapide.