38 replies to this topic

[MJ_]

Honestly, other software programs have managed to include this type of functionality with no speed detriment. Generally speaking, If someone reaches the point where they cannot enhance an application further without constant fear of performance penalties, then it's time to look at coding practices and the language it's programmed in. I don't believe that's the case here, though.

I agree. The operation of checking to see if a record exists in a file is a relatively quick process. Of course there are always interactions with the operating system, hard disk and third party programs like virus checkers and malware programs to consider as contributers to performance issues.

I do believe that Esword is ripe for refinement in a few areas. I'm sure Rick has things in mind and is working from a list of program enhancements as well as some modules that may help defray the costs of operation.

[BaptizedBeliever]

We might also consider that some of the modules (even on this site) have the bloated rtf code from MS Word which sometimes triples or quadruples the size of a module. I saved one in MS Word, ready to convert, and then converted with T4. It was 10 Meg. Then I saved it in T4 (which removes the bloated rtf code) and ran it again... 2.4 meg.

Perhaps some of that is to blame as well.

[Josh Bond]

How would anyone get MS Word RTF code into an e-Sword module? I know how I would do it, but, excluding Brent, I doubt there's anyone else who knows how to do that. Once you open an MS Word RTF document in ToolTip, it removes the bloat.

In other words: I don't think a module maker has inserted MS Word RTF into an e-Sword module, because if they're savvy enough to do it, they're savvy enough to know not to do it.

[JPG]

Hi Josh, would you be able to give a specific setup of resources that give you this 3-5 second delay (and describe where the delay is). Then each one could test it and report it here, along with some details of their OS and security, memory. Perhaps some useful feedback could be given to Rick Meyers.

Jon

[jonathon]

Then each one could test it and report it here,

Would the data from my stress testing of e-Sword be useful here?
Would making those "resources" available here, or elsewhere, be useful?

On second thoughts, that question should be:"Do you also want to be able to blow up your computer?"

jonathon

[MJ_]

How would anyone get MS Word RTF code into an e-Sword module? I know how I would do it, but, excluding Brent, I doubt there's anyone else who knows how to do that. Once you open an MS Word RTF document in ToolTip, it removes the bloat.

In other words: I don't think a module maker has inserted MS Word RTF into an e-Sword module, because if they're savvy enough to do it, they're savvy enough to know not to do it.

Are you trying to make RTF tags visible? Examples of RTF tags, something like that? Ahh.. or is it the MSWord that you specifically want? RTF files are quite bulky underneath the hood.

Edited by MJ_, 26 June 2012 - 02:39 PM.

[BaptizedBeliever]

My point was that if you create an rtf within MS Word, the rtf code is bloated. Then you open it in T4, and convert it from there, you will have a bloated bblx file. However, if you first SAVE the file in T4 before converting, the bloated rtf code is gone, and the resulting bblx file is much smaller.

For example, the MLV bblx file prior to this latest update from last week was around 10 megs. The new file (which I first saved in T4 before converting) is around 3 meg. There's not 7 megs worth of difference to the text. It was the rtf code from MS Word that was the culprit.

[Josh Bond]

My point was that if you create an rtf within MS Word, the rtf code is bloated. Then you open it in T4, and convert it from there, you will have a bloated bblx file. However, if you first SAVE the file in T4 before converting, the bloated rtf code is gone, and the resulting bblx file is much smaller.

For example, the MLV bblx file prior to this latest update from last week was around 10 megs. The new file (which I first saved in T4 before converting) is around 3 meg. There's not 7 megs worth of difference to the text. It was the rtf code from MS Word that was the culprit.

When you open a file in T4, it removes the bloat as you open the file. Even if you do not save the file, the bloat is still removed from the version in memory. And its that memory content that is used to generate a module. Saving an RTF file in T4 has nothing to do with keeping MS Word bloat out of a module--saving a file in T4 will remove the bloat from the RTF file permenately, but that's all. Either way, T4 re-writes the RTF before it ever goes into a module. T4 does this automatically, whether you save the RTF file in T4 or not.

The bloat from your Bible was not because of MS Word. It's because of a setting in T4: Use Old RTF Code. That setting produces dramatically smaller files when checked. If not checked, it's produces very large / verbose RTF code. Brent worked on this in recent versions--removing some of the clutter that this RTF control uses. But even still, the RTF control produces large files. Unless I have hyperlinks or images, I always make sure Use Old RTF code is checked to maintain smaller files.

When you re-generated your Bible recently, the difference is this time, you probably had Use Old RTF code checked and last time you did not.

[Josh Bond]

@Peter - this is where SwordSearcher works quite nicely (Swordsearcher is not free, by the way); all of the commentaries & dictionaries are linked right to each verse, and it looks like this (see screenshot)

I tried the 30 day evaluation of SwordSearcher. It has the most polished, well designed interface I've ever seen on Bible software, paid or free. It's not free though and it appears you have to pay for upgrades. And because it's not free, it doesn't have the level of interest e-Sword has, and therefore not the depth of resources. Beautiful software, though.