8000 Remove innecesary files · JayAyAre/PyScript-vs-JavaScript@565942f · GitHub
[go: up one dir, main page]
Skip to content

Commit 565942f

Browse files
JayAyAreJayAyAre
committed
Remove innecesary files
1 parent 9cca21e commit 565942f

File tree

6 files changed

+66
-161
lines changed

6 files changed

+66
-161
lines changed

‎.gitignore

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
1-
# Ignorar la carpeta de módulos de Node.js
1+
# Ignore Node.js modules folder
22
node_modules/
33

4-
# Ignorar dependencias de PyScript o Python si usas un entorno virtual
4+
# Ignore PyScript or Python dependencies
55
venv/
66
__pycache__/
77

8-
# Ignorar archivos de dependencias en Node.js
8+
# Ignore Node.js lock file
99
package-lock.json
1010

11-
# Ignorar logs y caché de npm
11+
# Ignore npm and yarn logs and cache
1212
npm-debug.log*
1313
yarn-debug.log*
1414
yarn-error.log*

‎Astro-TFG/src/layouts/IndexLayout.astro

Lines changed: 61 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -265,18 +265,22 @@ const { title } = Astro.props;
265265
>
266266
<li>
267267
<strong>JavaScript</strong><br />
268-
Sobresalió en operaciones nativas, aunque su rendimiento
269-
se degradó con estructuras de datos más complejas.
268+
Durante las primeras versiones destaco, sin embargo
269+
al implementar las optimizaciones de rendimiento
270+
en ambos entornos, fue superado abismalmente.
270271
</li>
271272
<li>
272273
<strong>PyScript</strong><br />
273274
Gracias a bibliotecas especializadas, superó a JavaScript
274-
en tareas ETL complejas, logrando un mejor equilibrio
275-
entre velocidad y consumo de memoria.
275+
en las tareas, logrando el mejor equilibrio entre
276+
velocidad y consumo de memoria, y superando en ambas
277+
a JavaScript..
276278

277279
<br /><br />
278280
La implementación con Web Workers mostró una escalabilidad
279-
más notable en PyScript que en JavaScript.
281+
más notable en PyScript que en JavaScript. Sin embargo,
282+
la inicialización de los workers en PyScript es mucho
283+
mas lenta que en JavaScript.
280284
</li>
281285
</ol>
282286
</ResultsCard>
@@ -288,13 +292,15 @@ const { title } = Astro.props;
288292
>
289293
<li>
290294
<strong>JavaScript</strong><br />
291-
Mantuvo un rendimiento constante con tiempos de renderizado
292-
significativamente inferiores en gráficos interactivos.
295+
Realmente en ambos tipos de graficos, tanto en graficos
296+
png o graficos interactivos tuvo la delantera ante
297+
PyScript.
293298
</li>
294299
<li>
295300
<strong>PyScript</strong><br />
296301
Requirió un tiempo considerablemente mayor para generar
297-
imágenes vectoriales de alta complejidad.
302+
los dos tipos de graficos, y ademas tuvo un rendimiento
303+
inferior en cada uno de los tiempos medidos.
298304
</li>
299305
</ol>
300306
</ResultsCard>
@@ -303,13 +309,11 @@ const { title } = Astro.props;
303309
<ResultsCard title="4. Manejo de solicitudes concurrentes">
304310
<ol class="list-decimal list-inside space-y-2">
305311
<li>
306-
<strong>JavaScript</strong><br />
307-
Superó a PyScript en todos los escenarios HTTP.
308-
</li>
309-
<li>
310-
<strong>PyScript</strong><br />
311-
Mostró una mejor escalabilidad al trabajar con WebSockets,
312-
acercándose al rendimiento de JavaScript.
312+
Realmente fueron los resultados mas parejos, en
313+
ambos casos tuvieron un rendimiento realmente
314+
parecido, sin embargo, por unas centesimas de
315+
segundos podriamos decir que JavaScript tuvo el
316+
mejor rendimiento en ambos escenarios.
313317
</li>
314318
</ol>
315319
</ResultsCard>
@@ -320,8 +324,10 @@ const { title } = Astro.props;
320324
>
321325
<span class="block">
322326
JavaScript demostró una superioridad absoluta en
323-
operaciones criptográficas SHA-256, acompañado de un
324-
menor consumo de memoria.
327+
operaciones criptográficas, tanto en las pruebas
328+
donde analizabamos los hashes de SHA-256 como en las
329+
pruebas donde analizabamos el cifrado y descifrado
330+
simétrico con AES-GCM.
325331
</span>
326332
</ResultsCard>
327333

@@ -331,15 +337,11 @@ const { title } = Astro.props;
331337
>
332338
<ol class="list-decimal list-inside space-y-2">
333339
<li>
334-
<strong>JavaScript</strong><br />
335-
Ejecutó el entrenamiento con mayor rapidez, aunque
336-
con una precisión ligeramente inferior en modelos
337-
complejos.
338-
</li>
339-
<li>
340-
<strong>PyScript</strong><br />
341-
Consumió más memoria, pero alcanzó una precisión
342-
superior a la de JavaScript.
340+
Estos resultados tambien dio unos valores
341+
iniciales parejos, donde ambos tenian una
342+
precision, uso de memoria, y tiempos parecidos,
343+
sin embargo en la segunda prueba JavaScript tuvo
344+
un rendimiento mucho mas optimo que en PyScript.
343345
</li>
344346
</ol>
345347
</ResultsCard>
@@ -354,13 +356,35 @@ const { title } = Astro.props;
354356
<p class="mt-4">
355357
El análisis revela que JavaScript mantiene la
356358
ventaja en la mayoría de los escenarios evaluados,
357-
especialmente en operaciones nativas y en tiempo
359+
especialmente en algoritmos e implementaciones tanto
360+
de forma nativa como en operaciones y en tiempo
358361
real. Por su parte, PyScript exhibe un potencial
359-
destacado en el procesamiento científico gracias a
360-
bibliotecas especializadas, aunque su sobrecarga
361-
inicial (carga de WASM e inicialización del
362-
intérprete) limita su uso en situaciones que exigen
363-
tiempos de respuesta inmediatos.
362+
destacado en el procesamiento de datos, donde las
363+
funciones y estructuras aplicadas a los datos
364+
gracias a bibliotecas especializadas, son realmente
365+
notables a la hora de analizar su rendimiento. Sin
366+
embargo, para realmente sacarle provecho a PyScript
367+
tenemos que tener dos entornos muy concretos, el
368+
primero es el entorno donde no tengamos recursos
369+
altos disponibles de memoria, y donde se este
370+
dispuesto a sacrificar tiempos de ejecución un poco
371+
más lento de lo normal. El problema? estos entornos
372+
son limitados ya que el mas parecido son los
373+
sistemas empotrados, pero estos requieren respuestas
374+
inmediatas, por lo que no podemos esperar mucho
375+
tiempo para obtener los resultados. El segundo es
376+
donde se requiera analizar un gran conjunto de
377+
datos, y donde el tiempo de respuesta es realmente
378+
importante, por lo que es necesario que se puedan
379+
obtener resultados en un tiempo razonable. Sin
380+
embargo, en ambos casos, PyScript sigue necesitando
381+
un tiempo de carga de la pagina inicial, que
382+
dependera de los modulos y del codigo Python, sin
383+
embargo eso afecta a la escalabilidad de su uso en
384+
el navegador. Por otro lado, si se usan Web Workers,
385+
se debe tener en cuenta el tiempo de inicialización
386+
de los workers, que en PyScript dio resultados muy
387+
lentos.
364388
</p>
365389
<p class="mt-4">
366390
La integración de Web Workers puso de manifiesto
@@ -370,7 +394,11 @@ const { title } = Astro.props;
370394
inicialización, lo que sugiere una mayor
371395
escalabilidad para procesos que contengan gran
372396
numero de workers. Sin embargo su espera a la
373-
creación de workers fue muy grande.
397+
creación de workers fue muy grande. Por lo tanto,
398+
PyScript es usable en entornos donde se requiere una
399+
escalabilidad de procesos, pero no en entornos donde
400+
el tiempo de carga inicial y el tiempo de creación
401+
de workers son importantes.
374402
</p>
375403
</div>
376404
</div>

‎Astro-TFG/src/pages/api/4.1.1/[delay].ts

Lines changed: 0 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -11,14 +11,10 @@ export const GET: APIRoute = async ({ params }) => {
1111
const delayString = params.delay ?? '0';
1212
const delay = Math.max(0, Number(delayString.split('.')[0]));
1313

14-
const start_time = performance.now();
15-
1614
if (delay > 0) {
1715
await new Promise((r) => setTimeout(r, delay));
1816
}
1917

20-
const response_time = performance.now() - start_time;
21-
2218
activeRequests--;
2319

2420
const data = Array.from({ length: 10 }, (_, i) => ({
@@ -30,7 +26,6 @@ export const GET: APIRoute = async ({ params }) => {
3026
JSON.stringify({
3127
status: 'success',
3228
delay,
33-
response_time,
3429
data,
3530
}),
3631
{

‎Astro-TFG/src/pages/api/run-4.4.1.ts

Lines changed: 0 additions & 64 deletions
This file was deleted.

‎Astro-TFG/src/pages/api/run-backend.ts

Lines changed: 1 addition & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,12 +4,6 @@ import { spawn } from 'child_process';
44
// Desactiva el prerender en Astro para permitir ejecución dinámica del lado servidor
55
export const prerender = false;
66

7-
/**
8-
* Ejecuta un script externo (Python o Node) como un proceso hijo
9-
* @param type - Tipo de script a ejecutar ('python' o 'node')
10-
* @param scriptPath - Ruta absoluta del script en el sistema de archivos
11-
*/
12-
137
function runWorkerProcess(
148
type: 'python' | 'node',
159
scriptPath: string
@@ -44,10 +38,7 @@ function runWorkerProcess(
4438
});
4539
}
4640

47-
/**
48-
* Endpoint HTTP POST que recibe tipo y ruta del script,
49-
* lo ejecuta en el servidor y devuelve su salida
50-
*/
41+
// Ejecuta un script externo (Python o Node) como un proceso hijo
5142

5243
export async function POST({ request }: { request: Request }) {
5344
const { type, path: relativePath } = await request.json();

‎Astro-TFG/src/pages/api/ws/[sessionId].ts

Lines changed: 0 additions & 45 deletions
This file was deleted.

0 commit comments

Comments
 (0)
0