Pregunta

Estoy usando TIBCO RV .NET API (TIBCO.Rendezvous.dll).

¿Sabe si hay una mejor manera, en términos de rendimiento, de recibir y leer mensajes de un canal de RV en C # ? Encontré que el tipo Message (el contenedor lógico sobre un mensaje RV) es bastante pesado. Obtener un campo por nombre o por índice podría ser bastante lento , especialmente cuando consideramos que es una operación recurrente / de alta frecuencia.

¿Alguna idea?

¿Fue útil?

Solución

El problema principal con el envoltorio c # es que:

  • Se asigna para cualquier acceso de campo (la api c / C ++ expone a los accesores rápidos fuertemente tipados para las primitivas más probables
  • marca las referencias en cada acceso a los campos (no es necesario que lo haga a menos que planee actualizar los campos posteriormente y desee evitar la pérdida de memoria)
  • las búsquedas de campos por nombre requieren la conversión de la cadena en una cadena ASCII de estilo C

Esos aspectos reducirán la sobrecarga de las búsquedas basadas en el campo / nombre subyacentes, que a su vez se pueden evitar cuando sepa que necesita mirar cada campo del mensaje mediante la iteración de los campos en orden. Esto es rápido en C / C ++, ya que funciona linealmente a través de la memoria y, por lo tanto, es fácil de almacenar en caché.

Personalmente envolvimos la api de C ++ directamente con la CLI de C ++ (en el momento en que la biblioteca .net era de calidad inferior). Resulta complejo hacerlo bien (especialmente si tiene múltiples dominios de aplicaciones) pero ofrece casi el mismo rendimiento que la API de C ++ (que es un envoltorio increíblemente delgado en la API de C).

Si su perfil le dice que las asignaciones dentro del acceso al mensaje están impidiendo que su aplicación se ejecute a la velocidad que necesita / quiere, me temo que tendrá un problema con la biblioteca .net. Puede usar la reflexión para llegar al IntPtr subyacente al mensaje nativo y luego usar las mismas funciones definidas externamente en MessageToolbaox (una clase interna en la dll) que se despliega en la api nativa, el costo de acceder al campo interno una vez por mensaje puede ser compensado por la búsqueda de campo más rápida. Obviamente, esto es frágil y difícil de mantener, pero si encuentra que vale la pena en comparación con la reimplementación completa de su envoltorio, podría ayudar.

Otros consejos

He visto lo mismo. Desde mi experiencia, el acceso a los campos en los mensajes de C # Rv es muy lento en comparación con el acceso a ellos en C ++. Por lo tanto, debe evitar agregar y leer varios campos hacia y desde el mensaje.

Una solución es no usar la serialización de mensajes de Rv. Es decir, no agregue muchos campos con Message.AddField () ni los obtenga con Message.GetField (). En su lugar, puede serializar sus datos a un tipo Opaco (que es un búfer binario, es decir, una matriz de bytes). A continuación, puede agregar este único campo al mensaje.

Si todo lo que haces es leer y escribir un campo, hay muy poca sobrecarga. Y debería ser capaz de serializar y deserializar los datos en su propio código bastante rápido.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top