Option storage

As I understand the code used by WordPress to set and get the values of an option from the database is smart enough to provide a good performance in these operations, in most cases the data is cached so I do not think that a separate implementation of this code would have a significant impact in the performance of the plugin.

Also if I create an interface and wrappers to duplicate the functionality of these WordPress functions just to handle the data in a single array, it means that I will have to maintain a code that is not really relevant for the plugin because WordPress already provides these methods.

One of my co-workers suggested to follow your recommendation and provide a modular interface to interact with the database, which supposedly will allow me to execute one single database query to retrieve all the plugin’ options at once and then handle the data in a (kind of) array as you suggest.

I am not completely sure if this modification will help to speed up the plugin. The parts that are slow in the code are the ones related with the file system scanners and the HTTP requests to the API service, so I would rather focus into improve these two things than the database readers.

I will create an internal task to test this, thanks.

Actually in the current state it take 0 extra DB query to get all of your options because you only use autoload=yes options.

I was pointing out that WP would do its autoload option query faster if you have one option that is an array. Thus the autload query would contain less rows. Now the autoload query includes your 20-30 options.

The wrappers would help you to code less to reach this “one-option” speedup.

That sounds good, I will give it a try.

Actually in the current state it takes 0 extra DB query

That is not true.
Initiall the non-existent options cause new DB queries.
Try enabling define( 'SAVEQUERIES', true ) and:

/**
 * Debug database queries.
 */
function debugger_dump_db_qeries() {
    global $wpdb;
    echo '<hr style="display:block; clear:both; width:100%" />
        <link href="//jmblog.github.io/color-themes-for-google-code-prettify/css/themes/vibrant-ink.css"
        type="text/css" rel="stylesheet" />
        <script type="text/javascript"
        src="//google-code-prettify.googlecode.com/svn/loader/run_prettify.js"></script>
        <pre class="prettyprint lang-php" data-vibrant-ink-no-class="linenums" style="white-space:pre-wrap;
        color:grey; font-family:monospace,serif; font-size:1em;"><code>';
    var_dump( $wpdb->queries );
}
if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES ) {
    register_shutdown_function( 'debugger_dump_db_qeries' );
}

Thanks @szepeviktor I am still profiling the new code and testing the other features that you were suggesting during the last week. I will update each ticket that you have created when I finish working on this.

This is the nicest reply I’ve ever received.

Commenting to move this to the first page; this suggestion is still relevant and I want to try this storage method to implement the feature requests of some users that want to have a way to export and import the settings, having an unique entry in the database may be easier to handle and keep the insertions/updates secure.