Je me demande à partir de quand on risque de sentir un ralentissement.
Avec du matos moderne, tu peux estimer la performance d'un PNRG basé sur un XOR-shift ou une congruence linéaire à ~500M/s. Je te laisse faire le calcul d'à partir de quel taux de remplissage de l'espace tu passes plus de 100ms à générer des nombres.
Après tu vas requêter ta BDD comme un bourrin pour voir si l'enregistrement existe, là ça va faire beaucoup plus mal et beaucoup beaucoup plus vite. En gardant une archi pourrie comme celle la, une technique est de minimiser le nombre de requêtes que tu vas faire pour vérifier si une URL existe déjà ou pas. Si tu as de la RAM avec un espace de 8G clés, utiliser un bitmap ça passe sans soucis. Mais tu peux faire un compris en utilisant des structures probabilistes à occupation mémoire sous linéaire. Soit de type set membership avec un bloom-filter, soit avec de la détection de doublon avec un Streaming Quotient Filter. Ca va vachement alléger le goulot qu'est la base.
Après la conception reste pourrie pour faire un truc sérieux, le service est voué à se dégrader alors qu'on peut très bien faire du non prédictible sans brute-forcer de pleins de manière. La plus conne serait de faire un shuffle une bonne fois pour toute de ton espace de clé, et ensuite de consommer élément par élément. Ca coûte n log(n), soit rien pour 8G élément, une bonne fois pour toute et après c'est constant. Mais il y a 100 façons différentes de faire un truc propre.
Après encore une fois, pondre un truc pour 2 utilisateurs ou 1 milliards c'est pas vraiment les mêmes objectifs dans la conception et la notion de "good enough"
[^] # Re: Engouement
Posté par ckyl . En réponse au journal J'avais envie de coder ce soir. Évalué à 6.
Avec du matos moderne, tu peux estimer la performance d'un PNRG basé sur un XOR-shift ou une congruence linéaire à ~500M/s. Je te laisse faire le calcul d'à partir de quel taux de remplissage de l'espace tu passes plus de 100ms à générer des nombres.
Après tu vas requêter ta BDD comme un bourrin pour voir si l'enregistrement existe, là ça va faire beaucoup plus mal et beaucoup beaucoup plus vite. En gardant une archi pourrie comme celle la, une technique est de minimiser le nombre de requêtes que tu vas faire pour vérifier si une URL existe déjà ou pas. Si tu as de la RAM avec un espace de 8G clés, utiliser un bitmap ça passe sans soucis. Mais tu peux faire un compris en utilisant des structures probabilistes à occupation mémoire sous linéaire. Soit de type set membership avec un bloom-filter, soit avec de la détection de doublon avec un Streaming Quotient Filter. Ca va vachement alléger le goulot qu'est la base.
Après la conception reste pourrie pour faire un truc sérieux, le service est voué à se dégrader alors qu'on peut très bien faire du non prédictible sans brute-forcer de pleins de manière. La plus conne serait de faire un shuffle une bonne fois pour toute de ton espace de clé, et ensuite de consommer élément par élément. Ca coûte n log(n), soit rien pour 8G élément, une bonne fois pour toute et après c'est constant. Mais il y a 100 façons différentes de faire un truc propre.
Après encore une fois, pondre un truc pour 2 utilisateurs ou 1 milliards c'est pas vraiment les mêmes objectifs dans la conception et la notion de "good enough"