Code: Select all
formatTime() 3300
numToStr() 4000
rsi() 200
string performance in PL
string performance in PL
It seems like string performance in PL can be improved. Below are some benchmarks in terms of CPU clock cycles for a call. Note that converting a number to string is 20 times more expensive than a call to compute the popular RSI indicator. Some of these string manipulation keywords are used heavily in strategy code. BTW, this is not a rub against PL performance since my benchmarks show that overall MC/PL runs 300-500% faster than TS/EL.
-
Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: string performance in PL
Hello orion,
Thank you for your suggestion. All feature requests are forwarded to the management of the company and are evaluated in a timely manner. Please note that even though we value your opinion not all requests can be implemented due to the fact that some features do not fit into our current roadmap.
Thank you for your suggestion. All feature requests are forwarded to the management of the company and are evaluated in a timely manner. Please note that even though we value your opinion not all requests can be implemented due to the fact that some features do not fit into our current roadmap.
Re: string performance in PL
Henry, thanks for the response. It was meant to be general information and I wasn't expecting a response. Improved string performance would be nice but is not on top of my list. If I could request features, in priority order they would be as follows:
1. More visibility into the datafeed and broker interfaces. Just the following five keywords would great:
datafeed.connectionStatus
datafeed.queuedQuotes // indicates datafeed quotes backlog
broker.connectionStatus
broker.orderSendTime // time that MC sent order to broker
broker.orderAckTime // time that MC received an order ack or order fill from broker
2. importData() and exportData() functions as discussed here to enable programmatic manipulation of the database. I use the database to store tick data that has been processed in a proprietary way. It requires a lot of manual exporting of tick data that MC has downloaded, processing it via external software tools, and reimporting manually back into MC database.
3. Make DLL calls faster. I have benchmarked MC DLL call to be 600 CPU clock cycles while TS DLL call is 100 CPU clock cycles. Both were benchmarked using g++ compiler with -O3 optimization. This is the only area where MC is slower than TS. MC is significantly faster in everything else. DLL calls allow one to offload performance critical functionality to native C++ code. However, such offloading is not wise if the call interface cost is high.
1. More visibility into the datafeed and broker interfaces. Just the following five keywords would great:
datafeed.connectionStatus
datafeed.queuedQuotes // indicates datafeed quotes backlog
broker.connectionStatus
broker.orderSendTime // time that MC sent order to broker
broker.orderAckTime // time that MC received an order ack or order fill from broker
2. importData() and exportData() functions as discussed here to enable programmatic manipulation of the database. I use the database to store tick data that has been processed in a proprietary way. It requires a lot of manual exporting of tick data that MC has downloaded, processing it via external software tools, and reimporting manually back into MC database.
3. Make DLL calls faster. I have benchmarked MC DLL call to be 600 CPU clock cycles while TS DLL call is 100 CPU clock cycles. Both were benchmarked using g++ compiler with -O3 optimization. This is the only area where MC is slower than TS. MC is significantly faster in everything else. DLL calls allow one to offload performance critical functionality to native C++ code. However, such offloading is not wise if the call interface cost is high.