2010-12-06 7 views
9

Buenos días,¿Rendimiento de C++/CLI en comparación con Native C++?

Estoy escribiendo un corrector ortográfico que, para el caso, es de rendimiento crítico. Siendo así, y ya que estoy planeando conectarme a un DB y hacer la GUI usando C#, escribí una rutina de cálculo de distancia de edición en C y compilé una DLL que uso en C# usando DllImport. El problema es que Creo que (aunque posiblemente estoy equivocado) que reunir palabras una a una desde String a char * está causando una gran sobrecarga. Siendo así, pensé en usar C++/CLI para poder trabajar directamente con el tipo String en .NET ... Mi pregunta es, entonces, ¿cómo se compara el rendimiento de C++/CLI con el código C nativo para cálculos matemáticos pesados ​​y acceso a arreglos?

Muchas gracias.

+0

Creo que CIL hace lo mismo pero implícitamente. –

+0

¿Por qué pasa palabras una por una? Pase el texto completo –

Respuesta

4

C++/CLI tendrá que hacer algún tipo de cálculo de referencias también.

Como todos los problemas relacionados con el rendimiento, debe medir y optimizar. ¿Estás seguro de que C# no va a ser lo suficientemente rápido para tus propósitos? No subestime las optimizaciones que hará el compilador JIT. No especule sobre la sobrecarga de una implementación de lenguaje únicamente para ser administrado sin intentarlo. Si no es suficiente, ¿ha considerado el código de C# inseguro (con punteros) antes de intentar con el código no administrado?

En cuanto al perfil de rendimiento de C++/CLI, realmente depende de la forma en que se usa. Si compila al código administrado (CIL) con (/clr:pure), no va a ser muy diferente de C#. Las funciones nativas de C++ en C++/CLI tendrán características de rendimiento similares a las de C++. Pasar objetos entre entornos nativos de C++ y CLI tendrá cierta sobrecarga.

+0

El código C# inseguro es aproximadamente el doble de lento que la función C que estoy importando con DllImport. – Miguel

1

No esperaría que el cuello de botella se encuentre con DLLImport.
He escrito programas que llaman DLLImport varias veces por segundo y simplemente funciona bien.
Pagará una pequeña multa de rendimiento, pero la multa es pequeña.

1

No suponga que sabe lo que debe optimizarse. Deja que el muestreo te lo diga.

He hecho un par de correctores ortográficos, y la forma en que lo hice (outlined here) fue organizar el diccionario como un trie en la memoria, y buscar sobre eso. Si el número de palabras es grande, el tamaño del trie se puede reducir mucho si se comparten los sufijos comunes.

+0

No es el caso ... De hecho, estoy usando un BK-Tree, por lo que mi enfoque es significativamente diferente al que dijiste. – Miguel

+0

@Miguel: OK, corregido. En cualquier caso, lo que hice fue una búsqueda por ramas en el trie, que funcionó bastante bien. Una alternativa es mezclar primero en profundidad/primero en amplitud, pero pensé que la rama y el límite era aproximadamente el mismo rendimiento y mucho más flexible, en términos de los tipos de errores ortográficos que podía manejar. –

Cuestiones relacionadas