In addition to extensive liaison with colleagues, standard design, implementation and testing of four Telepath SMS releases, the following significant tasks were completed.
Telepath Parameter Access
The major performance bottleneck in the system was always database access and with each release more of the database was cached in memory on SMS startup. Because of the large number of customers with varied requirements, Telepath was a highly configurable system with a huge number of parameters. These parameters were accessed in all parts of the SMS system and some of them could be further modified by particular applications on startup or by particular groups of users. I wrote a complex module that was used by each component starting up. For that component it worked out the value for each parameter instance taking into account application specified values, user group variations and maximum/minimum/default values set within the database. These values were then cached in such a way that they could be rapidly accessed. Parameters were grouped and applications could select which groups they wanted to periodically refresh from the database. These changes cut out a large number of database accesses across a wide range of Telepath components and formed a notable part in increasing the throughput of the system from 10 messages per second to 100 messages per second.
Memory problem due to large module size
After the Telepath 2600 release had gone from integration testing to system test it was discovered that all Telepath applications were large in size and the system was running out of memory. Some investigation found that this was due to a Telepath library which contained an module whose object size was greater than 4MB. In the space of a week I completely redesigned and rewrote this module. I reduced the module from over 1400 to about 500 lines of C code and in the process the object size was reduced from 4.48 MB to 44.7 KB which is slightly less than 1% of the original size. It was unit tested thoroughly and no problems were found with it in the system test phase.
Buggy library
Late in the Telepath 2600 release cycle it was found that a particular library was a source of many bugs. This library was used to configure different groups of users of the SMS system in different ways. In a short space of time I completely rewrote the module reducing it from over 2200 lines of code to about 1150 lines. This reduction meant that the code was more readable, maintainable and efficient. It was unit tested thoroughly and no problems were found with the redesign.
Message Structure and Data Dictionary
Up until the Telepath 2700 release every component in the system had its own structure for carrying message data. This meant that there was always copying of data from one structure to another and there was often confusion as different fields names were regularly used for the same data item. I completely reorganised the message structure for the 2700 release into 4 sub-structures. These were sequentially populated as the message passed through the SMS system thus removing the need for data copying. I also created a message data dictionary and there was extensive liaison with other developers in forming the dictionary components and encouraging them to use the dictionary names. The benefit of this is that it was then very easy to identify message attributes from a particular field name that appeared in code or a design document.
Library and Header File Tidy up
For the Telepath 2650 release I cleaned up the Telepath library layering so that mutual library dependencies were broken. This made interface definition far easier and reduced the complexity of the Makefiles where a library was often included up to three times on the link line. The common include files were also tidied so that each library had one exported header file whose name could be derived from the library name. This meant a much cleaner interface where applications could easily tell which header files must be included. An awk script was produced to help application developers remove redundant header files and insert in the necessary new ones. During the cleanup I tidied all common library files so that all compiler warnings were removed. The benefit of clean compiles was that future warnings during code changes were noticed. This often meant the elimination of bugs which would otherwise have been in the system.