Hi Chris,

I would love to explain about the efficiency among C++, Java and Python. 
Indeed, the pure Python code always perform the slowest among these languages. 
In machine learning workload, however, Python merely serves as a convenient 
task scheduler. The actual executors, such as CUDA, Tensor, NumPy, are built 
from C/C++. Therefore, we do not need to worry about the performance issue as 
TsFile becomes more and more covenient for Python toolchains under this 
workload. I hope my explaination could address your concern.

>From my perspective, TsFile's story would be more completeness with the 
>embracement of Python AI toolchains. Our community has made TsFile super 
>lightweight and efficient on the specified endpoint in the past decade, taking 
>the PLC environment as an example. Furthermore, the integration of Python 
>ecosystem could make TsFile from endpoint be directly employed on the cloud, 
>contributing to data analysis work.

Best regards,
Yongzao

On 2026/01/04 11:20:38 Christofer Dutz wrote:
> Hi all,
> 
> I would also like to give my +1 for a standalone viewer of TSFile payloads.
> This year, as soon as I have finished porting the PLC4X drivers to the new 
> architecture, my next goal will be to build PLC libraries for writing TSFile 
> data on PLCs directly and then to forward them to a server in regular 
> intervals via MQTT. So such a viewer component would be invaluable as a tool 
> to monitor what’s being written and what’s going over the wire.
> 
> Regarging shifting focus more to Python. As long as this doesn’t have 
> negative impact on the Java versions, I’m fine with that. But considering the 
> performance benchmarks shared on this list I am not sure if using TSFile 
> directly in Python is a good thing. I mean … its performance was always a 
> tenth of that of Java, C++ etc. Making it super convenient to directly use in 
> the Python toolchains, wouldn’t that make us use one of the key benefits of 
> TSFile … it’s performance?
> 
> Chris
> 
> 
> Von: Pengcheng Zheng <[email protected]>
> Datum: Mittwoch, 31. Dezember 2025 um 15:06
> An: [email protected] <[email protected]>
> Betreff: Re: Future Directions of Apache TsFile
> 

Reply via email to